[sorry Robert, for the direct reply] In bash, at least, the $IFS environment variable is used to specify the characters used to split arguments into their constituent parts. the $* function then uses the first character of this variable to join re-join the parts.
It wouldn't be very hard to have fish behave in the same way (if it doesn't already) when joining arrays, and therefore if you want to join arrays into a newline-separated string, it would just be a case of temporarily ensuring that "\n" was the first character of IFS Steve Stagg On Wed, Sep 21, 2011 at 3:24 PM, Robert Shinka <k...@unknownlayer.net> wrote: > 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 > ------------------------------------------------------------------------------ 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
