On Jan 8, 2008 6:46 PM, Isaac Dupree <[EMAIL PROTECTED]> wrote: > >> 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? > > is there any common ground on what different statuses mean between > programs, that we could look at? Otherwise, as long as fish isn't using > 125 already, sounds fine.
A bit of digging in the Posix standard gives me: "If a command is not found, the exit status shall be 127. If the command name is found, but it is not an executable utility, the exit status shall be 126." I could not find what the expected behavior is when execve fails. To me, using 125 seems reasonable. I've implemented this behavior. > > >> 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. > > me too, it's alright if verbosity varies. I guess I'm just concerned > about someone relying on the exit status and getting different results > (so maybe I'd prefer exit status 0 in addition to putting a message, > even though that's odd -- acting as if anything unknown is executable by > doing nothing?). I guess this is a rare enough circumstance and > probably no-one will be doing it intentionally, that it's okay if > prefixing a command with 'env' (usually an identity) produces a > different exit status Suboptimal, but I'm not a big fan of doing things badly just to be consistent. :-) Implemented the above error message. > > > 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. > > Sounds good to me. Although we should be careful about different > file-types. > > for example, directories. > when I `cd /var/lib/slocate` in bash, I get permission denied. (which is > rather confusing -- how can you not be allowed to `cd` somewhere, if you > know it's a directory, even if you don't have permission to _look_ > inside it?) > > but in fish, > /var/lib/slocate > (optionally prefixed by 'cd') produces > cd: "/var/lib/slocate" is not a directory > which is not true, so even more confusing. > > In particular, execute permission (not read permission) is needed in > order to cd to a directory. > > Which is considerably odd, since if I do `cd dskhjfjkh` (a directory > that doesn't exist) in fish, I get a clearer message (plus the red color > is a good clue that it doesn't exist) : > cd: "dskhjfjkh" is not a directory or you do not have permission to enter it > > if I type ./dskhjfjkh/ however I only get > fish: Unknown command "./dskhjfjkh/" > > and I suppose it's alright that it doesn't mention directories no matter > how directory-like I make the path look This is fixed in the darcs version of fish. The error messages from cd are now what you would expect. cd: "bbb" is not a directory cd: Permission denied: './aaa' cd: The directory 'ccc' does not exist for trying to cd to a file, for trying tocd to a directory that is not executable and for trying to cd to a non-existing directory, respectively. > > > File types: > > -doesn't exist > -if it's not executable, we don't do anything with it > -ordinary file > -directory > -device node (block or char) > -named pipe(FIFO) > -any other weird things I left out? socket? > -race conditions (changes between `stat` and action) > -symlink to any of the above > -symlink loop > > I suppose that anything besides > "[symlink(s) eventually leading to] executable file" > and > "[symlink(s) eventually leading to] executable directory" > is not a valid command to fish, since there's nothing obvious that it > would do. (although two separate paths are potentially searched, PATH > and CDPATH, so something might be found as a directory but not a > command, or vice versa, or both... oh dear. It appears that PATH a.k.a. > executable program is searched for first, which is the only reasonable > answer I guess.) Yes, I think the current behaviour is fine. It's a little bit complicated and it might second guess you to a small degree, but in my book it makes up for this by being both intuitive and powerful. > > > fish has really good potential for user-friendliness! In fact it already > is! I wouldn't be able to discuss these minor issues in quite this way > if it weren't for their resolution being an important goal I'm glad you think so! 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 [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
