On Jan 8, 2008 2:15 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: > > Axel Liljencrantz wrote: > > On Jan 8, 2008 1:06 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: > >> Axel Liljencrantz wrote: > >>> Are you sure, though, that fish has crashed? On my system, I can > >>> press any key and get the shell back. Having to press a key before the > >>> shell returns is obviously a misfeature, and possibly showing a stack > >>> trace on this error is a bit too scary to be the right thing to do, > >>> but at least nothing is crashing. Can you verify? > >> yes, I can verify as follows: > >> > >> until I hit return/enter, I can type characters and see them echoed, > >> delete and see them deleted, and press left-arrow and see junk appear > >> (so, readline isn't active at this point). Even if I type the first > >> character, delete it, and type more: after hitting enter, fish > >> interprets all but the first character on the line as a command. For > >> example, 'xecho 3' produces '3', 'echo 3' produces 'fish: Unknown > >> command "cho"', and 'x' produces simply two prompts in a row, as if I > >> had hit enter with a blank command-line. Pressing enter without there > >> being anything on the line at all, yields only one prompt and no message. > >> > > > > Ah, ok. Then it is not really a crash, but it is a bug. Here is what > > happens: > > > > 1). Fish forks of a child to execute the new command in. > > 2). The child is given control of the terminal. > > 3). The child calls execve to run the new command. > > 4). Execve fails. > > 5). The child shows an error message. > > 6). The child reads a single character of input. > > 7). The child exits and control of the terminal is given back to the parent. > > > > Step number 6 is not really called for. It is there so that if the > > shell proper crashes, you will see the error message instead of having > > the terminal die on you, thus losing the error message forever. It > > shouldn't happen in child processes. I've removed step 6 now, so that > > the child simply exits. > > so now that causes an ugly error but followed by a prompt? (I'd test the > darcs version, but then I thought, is it safe to run different versions > of fish at the same time? because of universal variables / fishd) That > behavior's much more friendly, but it would still be nice if it could > print a message describing the problem, rather than a "execve: Exec > format error" and fish-backtrace.
True. > > for reference, > bash, ash, sudo, and env output nothing and exit with success (status 0) > when trying to execute such file. > zsh prints: > zsh: exec format error: ./somefile > and the command fails with exit status 126. > fish currently has the command fail with exit status 1. Hmm, right. 1 is is a silly status. Bash exits with status 0 in this case. Bash also uses the following statuses: If a command is not found, the child process created to execute it returns a status of 127. If a command is found but is not executable, the return status is 126. I think having different statuses for different events this way is a good idea. If a command is found, is marked as executable but is not really a valid executable file is, in my view a separate event and should have another status. Perhaps 125? > > I think it would make sense for the command to fail and to give a > message like "fish could not figure out how to execute this file" (or > preferably something more accurate, as it's libc/kernel that are the > ones that actually decide how to execute a file). However that produces > inconsistency with command-helpers like 'sudo' and 'env', which is > unfortunate, and possibly enough reason to reconsider. I'm fine with fish being more verbose than e.g. sudo. Suggestions on a good wording are welcome. Perhaps something like: fish: The file "./foo" is marked as an executable but could not be run by the operating system. > > > > > Also worth noting here is that because the terminal is buffered, you > > will have to enter a complete line of input before a single character > > is returned to the child, which is why you get the weird behaviour. > > This should probably be fixed as well, for the cases where the shell > > proper crashes and this feature actually should be used. > > because you want just one character of input to make the shell quit (and > therefore the terminal probably vanish)? Admittedly when the shell has > actually crashed, the fancier a thing you try to do, the less likely it > is to _work_ in any given crash :-) True. That is a pretty good reason not to try and mess with the terminal any more than needed when a serious error happens. Axel > > -Isaac > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
