Tiny Core Base > Release Candidate Testing
tinycore & microcore v2.0rc4.
mcewanw:
--- Quote from: roberts on June 01, 2009, 09:28:55 PM ---may I sugest that since .jwmrc is under your control, i.e., in your backup by default, remove in the three calls to aterm the -e /bin/sh and verify that .ashrc will be re-read for an updated environment in the new aterm, and finally post your results.
--- End quote ---
Using tc2rc2.4 with jwm.
Assuming what you meant, I modified part of .jwmrc to:
<Menu label="XShells">
<Program label="Dark"> exec aterm +tr -T "sh"</Program>
<Program label="Light"> exec aterm +tr -bg white -fg black -cr blue -T "sh" -e /bin/sh</Program>
and rebooted.
[I purposively left the -e /bin/sh on the "Light" terminal for comparison purposes]
I then started up a few aterms and emelfm2 apps using the following different methods to see the result in terms of the number of sh processes that are left running:
1. Dark aterm started from jwm menu
2. Dark aterm started from jwm menu
3. aterm started using: aterm & (from commandline)
4. aterm started using: aterm & (from commandline)
5. emelfm2 started from jwm menu
6. emelfm2 started from jwm menu
7. emelfm2 started using: emelfm2 & (from commandline)
8. emelfm2 started using: emelfm2 & (from commandline)
9. Light aterm started from jwm menu
10. Light aterm started from jwm menu
The following is the result from running command "ps".
Note how running emelfm2, for example, from commandline (items 5 and 6 above => pids 6595 and 6598 below) don't result in an extra sh process running. In other words, starting apps from jwm seems to result, as I said in a lot of overhead in terms of extra sh processes.
In the aterms which weren't started with -e /bin/sh, I entered du and the result was actually a du -h, which shows that .ashrc was being read since the alias du equals du -h was from there.
--- Code: --- 6639 tc /usr/bin/aterm
6640 tc sh
6651 tc /usr/bin/aterm
6652 tc sh
6663 tc aterm
6664 tc sh
6675 tc aterm
6676 tc sh
6687 tc sh -c /usr/local/bin/emelfm2
6688 tc /usr/local/bin/emelfm2
6691 tc sh -c /usr/local/bin/emelfm2
6692 tc /usr/local/bin/emelfm2
6695 tc emelfm2
6698 tc emelfm2
6703 tc aterm +tr -bg white -fg black -cr blue -T sh -e /bin/sh
6704 tc /bin/sh
6716 tc aterm +tr -bg white -fg black -cr blue -T sh -e /bin/sh
6717 tc /bin/sh
6728 tc ps
--- End code ---
Unfortunately I'm preparing for a job interview next week so can't investigate this much more just now sorry.
Great distribution this, by the way. Fantastic to work with in terms of its ease of adaptability. Can't be bothered using any other Linux distribution now...
mcewanw:
I repeated some of "the experiment" on a different Linux distribution (which also uses jwm but didn't by default have aterm or emelfm2, so using rxvt and leafpad).
Half of the following rxvt shells were started with jwm menu; the other half with rxvt &
The same goes for leafpad.
As you can see there are no extra bash (shell) process overhead associated with the started leafpad whether started from jwm menu or from the commandline with leafpad &.
7628 root 2772 S rxvt
7629 root 2800 S bash
7705 root 2772 S rxvt
7706 root 2796 S bash
7819 root 2772 S rxvt
7820 root 2796 S bash
8299 root 2788 S rxvt
8300 root 2796 S bash
8375 root 2788 S rxvt
8376 root 2796 S bash
8471 root 2788 S rxvt
8472 root 2796 S bash
8608 root 13244 S leafpad
8633 root 13344 S leafpad
8655 root 13344 S leafpad
8693 root 13344 S leafpad
8794 root 13320 S leafpad
8818 root 13320 S leafpad
8858 root 1600 S sleep 2
8859 root 2312 R busybox ps
jpeters:
adding alias cl=clients to .ashrc with .jwmrc: <Program label="Dark"> exec aterm +tr -T "sh"</Program>
tc@box:~$ cl
8073 tc /bin/ash /home/tc/.local/bin/clients
8074 tc wish8.5 /mnt/hda3/MyFiles/clients
mcewanw:
--- Quote from: roberts on June 01, 2009, 09:28:55 PM ---There is some history as far as the aterm call from .jwmrc goes:
Currently aterm is called with the -e /bin/sh option (extra shell).
--- End quote ---
The problem I am referring to is with /usr/local/tce.wbar and pretty much 'all' the entries in /usr/local/tce.menu
Since the issue concerns so many extensions, fixing the problem appears to me to involve quite an undertaking, unless TCbase can be modified to address the issue, because the tce.menu entries are inbuilt into every tce and tcz.
For emelfm2, for example, the relevant c: entry line in tce.wbar currently needs to be changed
from: /usr/local/bin/emelfm2
to: exec /usr/local/bin/emelfm2
/usr/local/tce.menu/emelfm2 (as provided by the tce and tcz extension creator) needs to be changed
from: <Program label="emelfm2">/usr/local/bin/emelfm2</Program>
to: <Program label="emelfm2">exec /usr/local/bin/emelfm2</Program>
Unless, that is, all the unnecessary sh processes which are currently left running (because of the missing "exec" instruction) are considered acceptable, but that would hardly fit in with the minimalist philosophy and is a major bug and unacceptable system overhead IMO.
If TC core itself can't be modified to remedy the problem, then it seems that pretty much all extensions need to be fixed to include "exec" at the front of the application run path in the associated tce.menu entry. There appears to me to be no simple fix for the user.
Also, the Wiki page about creating iconmenus should also be altered to reflect the need to include the "exec" instruction within the Program label run application stanza.
I note that the aterm, cpanel, and appbrowser references in /usr/share/wbar/dot.wbar DO include the exec in front of the application run path, so TC core appears to be "correct" in that sense. The same applies for these particular apps as far as .jwmrc is concerned.
jpeters:
Kindof like the difference between running "$RED" and "echo $RED". Both work, but the former
involves sh in a different way.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version