>> 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. >> 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 > 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 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.) 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 ~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
