* Michael Stone said: > > can forget about the case as above with a perl/whatever script returning a > > 127 error code. Either way, the error code _bears_ a possibility of being > > returned by the dynamic loader and it's better to be safe than sorry. > > That wasn't the point. Did you try what I wrote? The point was that > bash's return code is the return code of the program last executed by > bash--it's not necessarily something determined by bash itself. You > can't rely on the content of bash's return code because you have *no* > control over what I run in my bash session, or what it might return. And > no, it's not better to be safe than sorry if your idea of "safe" has the > possiblity of starting *two* shells when I use root's shell. First, the wrapper I suggested would *only* run at the login time, so there is no your bash session at that time. Granted, there can be a script invoked from your shell startup scripts but if your shell gets to execute these it won't fail and the wrapper won't ever get to test it's return code, right? And the wrapper will silently wait a second or two for your shell to load (or fail) and then check whether it is running (using, e.g. waitpid). If so, it will exit and remove itself from the memory. If, on the other hand, your shell fails for *some* reason it will, regardless of the exit code, exec the emergency shell. I should've made myself more clear - the 127 return code will be used just to tell the user "hey, it might be your dynamic linker that failed to load your standard shell. Check whether everything's ok with your dynamic libraries". Nothing more, nothing less. marek
Attachment:
pgpbUGtAxfbJb.pgp
Description: PGP signature