On Wed, Sep 21, 2011 at 10:36:41AM +0200, Jan Kanis wrote: > On Wed, Sep 21, 2011 at 03:07, Robert Shinka <[1]k...@unknownlayer.net> > wrote: > > In both fish-1.23.1 and the latest git, it does not work that way. > > set var a b c d (echo e\ \ f\ng) > > set | grep \^var > var 'a' 'b ' 'c' 'd' 'e f' 'g' > > echo $var > a b c d e f g > > Then my fish indeed works differently from yours. > ~/temp> cat fishtest.fish > set var a b c d (echo e\ \ f\ng) > set | grep \^var > ~/temp> . fishtest.fish > var 'a' 'b' 'c' 'd' 'e f' 'g' > > I've attached the fishtest.fish to avoid mangling by mail programs. Does that > indeed give different output on your machine? I'm running git master, commit > id 157ca12. Version 1.23.1 (as tagged in git) works the same for me.
No, it works as expected. I now recognize this as a locale issue: I was inadvertently inserting non-breaking space, which fish understandably did not interpret in the way I expected... please disregard. > It's not necessary to keep track of that whitespace, and I would rather > fish didn't (including in the example I gave above, which is just odd). > > What I expect 'set' to do is store each element passed to it as a > separate element in an array: the same way it does now, except for that > oddity in argument parsing (which should probably be fixed, but I'm > uncertain of the reason for it). > > Then, when expanding that array, offer two expansion forms: $var, which > passes each element as a separate argument the way it does now, and > "$var", which formats the contents into a single string, with each > element separated from the next with a single \n character. In the case > of output from a command, this could also be optimized to store the > string directly, if desired, for a significant performance boost. > > Your 'myset' function would also work as expected given this behavior. > > Ah, so you're not proposing that "$var" gives back the *original* string, > just > that it joins the separate elements with \n instead of space. In the case of output returned from commands, it would be the same as the original string. In the case of values passed to set itself, or via appends to the array, there's really no reasonable definition for what the original string is, because the array is no longer formed from a single string: each item is interpreted as a new element, and we need those elements delimited by /something/ if we're going to concatenate. So, yes, just joining with \n gives the desired behavior. > I agree with you that the "$var" syntax where var is an array is not very > useful. At least I can't remember having used it with array variables. (I > have > for one-element variables, but your proposal won't change anything for > those.) > But I doubt your proposal will be that much of an improvement, once the > "(command)" syntax is implemented. Are there any uses for it that are not > covered by "(command)"? Yes, although it's primarily to make arrays useful in their own right. For instance, two equivalent sequences would be: set var a b c d e; echo "$var[2 3 4]" set var a\nb\nc\nd\ne; echo $var | head -n 4 | tail -n +2 Similarly, consider: set var[2] bravo set var "(echo $var | head -n 1)"\nbravo\n"(echo $var | tail -n +3)" If "$var" doesn't have that behavior, how do you do meaningful work with arrays? How do you get back a sane string representation after storing the result of a command that was split? The answer is the original (ugly and inefficient) hack given earlier. You could do everything that the either change would accomplish with some combination of head, tail, echo, sed, or extra variables and string concatenation, albeit in a more cumbersome and inefficient way. I would prefer we made both changes and saved users the frustration. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Fish-users mailing list Fish-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fish-users
