On 4/24/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 4/24/06, Axel Liljencrantz <[EMAIL PROTECTED]> wrote: > > On 4/23/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > > 'echo %man\ ls' works. 'echo man %"man ls"' does not work with the > > motivation that 'echo $"PWD"' doesn't work. Maybe they both should? > > Perhaps. '$"PWD"' looks weird -- a variable name will never contain > characters that need quoting. But the % construct does contain such > characters.
True. If $"PWD" should be allowed, it would only be in order to keep things consistent. Then the question of course arises, should $"P"WD be equivalent to $"PWD"? I'm not really thrilled about the thought of messing with quotes and variable expansion. > > > > Also, I'm curious -- why did you decide to make "jobs" print a message > > > when there are no jobs? I think it should print nothing. > [...] > > we have lost our modelessness, and therefore I see no great > > crime in increasing the difference between interactive and script > > output of 'jobs' if it makes sense. > > I agree. > > > [...] When running jobs in interactive mode, it makes at > > least a bit of sense - I am generally untrusting when it comes to > > computers. If I ask the computer something, and it gives me _nothing_ > > in response, I'll have some sneaking suspicion that the computer > > didn't understand what I asked it. I want the computer to explicitly > > tell me 'I have nothing to say to you, now go away'. > > :-)) I guess this makes sense. Do you feel the same way about > listing an empty directory or printing the value of a non-existent > variable? I prefer (a bit) the computer to tell me nothing, in all > those cases, including "jobs". This way I get the message (that there > is nothing to say) more easily than having to read it. True, if I > write a command that is syntactically valid but not semantically what > I mean, then I will get no explicit mention. > > It's not a big deal for me either way. > Directories: Yes. Variables: A qualified 'Probably not' Motivation: For directories, the same logic as with 'jobs' applies. It's not my call, though, I didn't write 'ls'. For variable expansion, it is not unusual that you know that something will expand to nothing, and this is ok. It's hard to know when to print warnings and when not to. Fish is quite a bit wordier than other shells, it even goes as far as to write out function stack traces with line numbers and parameter lists on many types of errors. I think this is a good thing, other shells are much too cryptic. But sometimes verbosity just gets in the way. Fish walks this fine line when it comes to wildcard expansion. It will not run a command if none of the wildcards in the perameters produce any matches. In interactive mode, fish also prints a warning about skipping this command. There are cases where the fish behaviour is not ideal, but I think it is much closer to ideal than the bash behaviour, and comparable in complexity. I also think that even more complex rules for when to do what would be too confusing. If there are clear cut cases where a variable expansion is very unlikely to produce the intended result, I'd like to print a warning, but probably not in the general case. The exact balance here is really hard, and fish gets it wrong sometimes. Changes are still happening in this area. If anyone finds an error message that is either too terse or too wordy, or a situation where fish doesn't print an error when it should or a situation where fish prints an error even though nothing bad really happened, send a message to the list. -- Axel ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Fish-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fish-users
