tinycore & microcore v2.0rc4.

[^thehatsrule^]

Some previous discussion: http://forum.tinycorelinux.net/index.php?topic=476.0

[roberts]

As I wrote before, it has to do with the changing of busybox and ash shell. Each time I have updated busybox there has been changes and continues to be improvements with the shell applet.

A extra shell is not a show stopper. All applications run. I has been trying to keep uptodate with busybox. But in case you haven't noticed, I have spent most of my time in improvements in other areas, witness the change log.

Again, a comparision, to other distros is not helpful, as what was posted is bash not busybox's ash applet.

But for those that think this represents that "the sky is falling", here is a little test, a work around if you will.

1. Have bash.tce load and ready for use.
2. Exit X environment, i.e., Exit to prompt
3. sudo ln -sf /usr/local/bin/bash /bin/sh
4. startx

Now starting said applications do not have an extra shell.

I see again, another update to busybox and ash shell is in their change log. I will compile and test.

I do not recommend the massive changes as was mentioned.

[robc]

has there been any changes to how the desktop handles icon management? or in other words, does TC 2.0 only support wbar as an icon manager?
or is that something for the next release?

I ask this because pcmanfm has the ability to manage the desktop icons and I would like to know if the icons are going the same route as the window managers have in the next set of releases.

PS - the new kernel for 2.X is giving me a bug when I try to boot on my P4 machine (Dell Dimension 4300) 

[mcewanw]

As I wrote before, it has to do with the changing of busybox and ash shell.

Sorry, I thought you were just talking about some issue with aterms specifically and didn't make the overall connection you were trying to put across. I compared with another distro because it seemed from the replies I was receiving that I hadn't myself managed to describe the issue very clearly, so I needed (I thought) and example.

But for those that think this represents that "the sky is falling", here is a little test, a work around if you will.

1. Have bash.tce load and ready for use.
2. Exit X environment, i.e., Exit to prompt
3. sudo ln -sf /usr/local/bin/bash /bin/sh
4. startx

Now starting said applications do not have an extra shell.
. . .
I do not recommend the massive changes as was mentioned.

But the above is a great answer that should certainly remove any problem from my point of view since I use bash by default anyway since it is a dependency of some of the apps I routinely use.

Some previous discussion: http://forum.tinycorelinux.net/index.php?topic=476.0

Thanks for the link, I was wondering why no-one seemed to be commenting about the extra sh processes, but I missed that thread.

[mcewanw]

Kindof like the difference between running  "$RED" and "echo $RED". Both work, but the former
involves sh in a different way.  

A extra shell is not a show stopper.

Not an overall show stopper, not at all. However, I was not being picky or pedantic, such issues can make a difference, and can be a show-stopper for some issues (or at least require unexpected workarounds).

I created a front-end system for yasr, speech-dispatcher and espeak just over a year ago; a project called foksyfeyer, which attempts to increase accessibility to computing for the visually impaired (and particularly for those who are entirely blind). As part of that system I also wrote an interprocess comms utility (a simple shell actually) called "wiak" which uses system V message passing to communicate between processes under bash. "wiak" will probably work fine with busybox ash shell, but yasr certainly behaves differently and routines which can terminate the speech system no longer work because of the extra shell being left behind (the console freezes). Of course there will/might be fudges and workarounds, which would involve re-writing part of foksyfeyer (and the more universal a solution the better of course), but since bash is a dependency of the system anyway, making the soft link you suggested is the best solution for now anyway.

I do think it is important to avoid extra shells lying around. At a system level grabbing control of the shell and process handling is already an intricate enough task, as a C programmer, without the additional problem of different and inconsistent shell behaviours.

The extra shells should not be generated, they are a waste of resource and have no practical purpose, and can mess other things up! So no, there is nothing fussy or pedantic or trivial about the concern I reasonably raised; the comment: "Both work, but the former involves sh in a different way" trivialised the issue and was of no help at all.

[roberts]

has there been any changes to how the desktop handles icon management? or in other words, does TC 2.0 only support wbar as an icon manager?
or is that something for the next release?

I ask this because pcmanfm has the ability to manage the desktop icons and I would like to know if the icons are going the same route as the window managers have in the next set of releases.

PS - the new kernel for 2.X is giving me a bug when I try to boot on my P4 machine (Dell Dimension 4300) 

Currently TC only supports wbar. But I have placed some hooks to provide other icon support. I just have too much on my plate with trying to get 2.0 final to think or discuss further. Once 2.0 final is out and I have some time to catch my breath, I will look into supporting other icon management systems.

[jpeters]

Kindof like the difference between running  "$RED" and "echo $RED". Both work, but the former
involves sh in a different way.  

the comment: "Both work, but the former involves sh in a different way" trivialised the issue and was of no help at all.

I wasn't trivializing anything. I thought there might be a comparison with your example  regarding how 'sh' kicks in when the command isn't present..... jeeech.....have to watch what we say around here.....

edit...Looks like there's no extra process involved anyway....just doesn't require ". /etc/init.d/tc-functions" as with bash.