On 8/17/06, Martin Baehr <[EMAIL PROTECTED]> wrote:
> On Thu, Aug 17, 2006 at 02:09:59PM +0200, Axel Liljencrantz wrote:
> > You are correct that [] and {} are not identical, but fish does not
> > have both because they are so strongly related, just as Jamessan said.
>
> i never saw them as related, but ok.
>
> > I have found that in all such situations I have encountered in the
> > real world, it has been easy to sneak in a ?-wildcard somewhere in a
> > safe manner to only get the files that really exist.
>
> hmm, i can't think of a way how to do that in the examples i gave.
> could you try and show how you'd do that?
You can usually use e.g. 'ls *foo{1,2,3,4,5}' or 'ls ?oo{1,2,3,4,5}'
instead of 'ls foo[12345]', though this obviously relies on either
there being no files like 'aaafoo3' or 'boo2', respectively. So there
is always the chance that this won't work in a specific case. It is a
kludge, so if you do this often, then it is of course not a good
solution.
>
> > If so, I would suggest the inclusion of a null-wildcard-operator, one
> > that does not match any output, but all non-existing paths are
> > dropped.
>
> sounds interresting...
>
> > The idea here would be to instead of having two nearly-identical
> > features, like {} and [], to have two unrelated features that together
> > do all the things you could do previously and many that were very
> > cumbersome before as well.
>
> indeed. and i can see some nice additional uses already,
> because [] only operated on single chars, while {,} works on strings
>
> > Another thing worth considering is how often you'd want to use this
> > null-wildcard.
>
> very often.
> more often if it were easier to use.
> my most common need is to cover a range of numbered files.
> so a really nice feature would be to write something like:
>
> ls foo{12..55}.ext
> and have that expand to all values between,
> but now reduced to the files actually existing.
>
> hmm, actually foo(seq 12 55).ext does the expanding part already.
>
> it is amazing, for every problem in fish i find a few new great
> features. so on the competition of bash vs fish, so far, fish is
> winning. (and that means a lot, considering that i use unix since 1992)
I'm very happy to hear that. Though I'm also happy to hear of any
problems you have, since they point out places where the language can
be made better.
>
> > Only things that are common enough that writing it out as a command
> > would be cumbersome should be made into operators of the language
> > itself.
>
> agreed.
>
> > function isfile
> > for i in $argv
> > test -f $i; and echo $i
> > end
> > end
>
> adding a function on the commandline only seems to work if it is on
> one line. being able to just paste the code into the shell would be
> nice.
Yes. Multiline editing on the commandline has been on my todo-list for
a very long time. I do hope to have the time to do this soon, but I
have been hoping for a long time.
>
> > touch (isfile foo{1,2,3})
> > the former is admittedly much longer/uglier, but if this is done very
> > rarely, that should be offset by the fact that it is easier to learn a
> > small language, that it is easier to find out what the code does if it
> > contains only functions and commands instead of weird operators, etc..
>
> very true.
> i'll play around with the function and see how far it gets me.
> is there a way to make it throw an error if the list is empty?
I've never though about that, but it does make sense that command
substitutions would be able to stop the calling process from
executing. Not currently possible, but it should be. The obvious way
would be by returning a non-zero exit status. In other words the
command
fish> echo This message is never printed (false)
would never execute (unless you overload the false command).
There are two problems I see with this:
1). Some commands might sometimes return non-zero exit status for
minor issues where you'd want the command to continue.
2). In a command with multiple command substitutions, should the
command fail if only one substitution fails, or only if all of them
fail?
The first issue should be pretty rare, it is in my experience more
common for commands to return 0 even when they fail. When it happens
it can be made much less confusing by printing a warning, like fish
currently does when no wildcards match, something like:
> echo (false) blah
fish: Warning: The command substitution '(false)' failed. The calling
command will not be executed.
echo (false) blah
^
The second issue is a bit muddy for me. On one hand, it seems more
intuitive to fail on the first failed substitution. On the other hand,
wildcards only fail if all a commands wildcard fail, so that would be
more consistent.
>
> greetings, martin.
> --
> cooperative communication with sTeam - caudium, pike, roxen and unix
> offering: programming, training and administration - anywhere in the world
> --
> pike programmer travelling and working in europe open-steam.org
> unix system- bahai.or.at iaeste.(tuwien.ac|or).at
> administrator (caudium|gotpike).org is.schon.org
> Martin Bähr http://www.iaeste.or.at/~mbaehr/
>
--
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&kid=120709&bid=263057&dat=121642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
