On Mon, Sep 19, 2011 at 17:06, Robert Shinka <k...@unknownlayer.net> wrote:
> On Mon, Sep 19, 2011 at 04:18:18PM +0300, Philip Ganchev wrote:
> > On Mon, Sep 19, 2011 at 1:47 AM, Robert Shinka <k...@unknownlayer.net>
> wrote:
> > > On Sun, Sep 18, 2011 at 09:20:21PM +0200, Jan Kanis wrote:
> >
> > >> Bash treats command substitution and variable expansion as a list of
> > >> whitespace separated tokens. It also includes escapes to treat both
> as a
> > >> single token, in case you don't want the default behaviour.
> > >>
> > >> Fish does the same for variables, except it doesn't split the
> contents when
> > >> the variable is used, but it stores the tokens in a structured way as
> an
> > >> array. Command substitution works a bit differently. Maintaining a
> structured
> > >> form of data like with variables isn't possible because it is output
> from
> > >> arbitrary commands, so fish splits the command output like bash does,
> but only
> > >> on newlines. However fish doesn't provide a way to prevent the
> splitting.
> > >
> > > If fish reconstructed "$var" the same way it split it (with \n), then
> > > your problem wouldn't exist. You could work with lines as usual with
> > > $var, and "$var" would produce the exact data it was created with.
> > > If anyone needed a space-separated version of the string for whatever
> > > reason, they could trivially do so with echo or tr, but I think that's
> a
> > > rare case. Right now, there's no reasonable utility.
> >
> > Yes, that would be more logical. But separating with spaces saves
> > screen space when printing the array, which is quite a common
> > operation.
>
> I'm only proposing changing the semantics of "$var", while $var would be
> unchanged, so the common case of (echo $var) would format as usual,
> separated with spaces, but (echo "$var") would print the original
> string, including any embedded newlines.
>
> eg.,
> > set var (echo 1\n2\n3)
> > echo $var # echo '1' '2' '3'
> 1 2 3
> > echo "$var" # echo '1\n2\n3'
> 1
> 2
> 3
>
> Is there a compelling reason not to make this change?
>
Yes.
First of all, the internal representation of variables would have to be
changed, because they don't store the whitespace that separated the array
elements/arguments. Fish splits the result of command substitutions on \n,
but in other cases it uses other whitespace:
> set var a b c d (echo e\ \ f\ng)
# a<space>b<three spaces>c<tab>d<space>e<two
space>f<newline>g
> echo $var # 'a' 'b' 'c' 'd' 'e f' 'g'
a b c d e f g
> echo $var[4]
d
> echo $var[5]
e f
If 'echo "$var"' as you propose is to work on this example, the internal
representation of 'var' will need to remember what whitespace was used
where. But this is merely a programming problem.
The real problem is that the 'set' command itself doesn't have access to
that whitespace. 'set' is just a regular command, it is not special syntax
such as 'for' etc. It just receives a list of arguments in it's $argv (or
the builtin command's equivalent) and works with those, just like any other
builtin/function/external command. If 'set' is to remember the whitespace,
it will need to become a special case (and the only one at that) for fish's
generic argument-parsing code. It would also be a very non-obvious and non
composable special case: a function like "function myset; set $argv; end"
wouldn't work.
There's also no benefit to doing this: fish already has a way to store
whitespace in variables, but you need to indicate what you want when *
assigning* the variable instead of when using the variable like in your
proposal. Just do
> set var "a b c d"
The problem is that there's no way to handle command substitutions in this
form.
If quoting command substitutions were allowed, the above could be done. It
would also solve your example:
> set var "(echo 1\n2\n3)"
> echo $var # echo 1\n2\n3
1
2
3
I'd be willing to endorse that, as it does fill another hole in fish's
> string-handling capabilities, and should make some tasks a lot easier.
> The only question that remains then would be whether to allow escaping
> parentheses inside strings to prevent evaluation, or simply require the
> use of '' rather than "" where it's not desired.
>
> There is one significant downside, however: a little breakage with user
> scripts is likely, but updating them should be very simple.
>
Yup, that's a downside. But I also think it's acceptable. I think escaping
parentheses in double quotes should be allowed, just like the dollar sign
and other special characters.
------------------------------------------------------------------------------
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
