On 04/04/10 05:15, Beni Cherniavsky-Paskin wrote:
> On Tue, Mar 30, 2010 at 21:35, Isaac Dupree
> <[email protected]> wrote:
>> oh, how odd! It looks like it turns each LF into a space character,
>> (except for the final trailing LF which it deletes, as per standard for
>> process-substitution operators). This leaves the CRs around to make
>> stupid-looking output (in a terminal, they move the pointer to the left
>> side without moving it down a line).
>>
> Well, CRs are generally stupid in unixland. But yes, fish should
> probably strip them.
It could also manipulate them along with the LFs, intelligently!
Although I admit that in a unix-command-substitution context, this is
likely to be unimportant... already by removing the newline at the end,
it's not binary data and it's likely just consumed by another unix command.
>> Turning LFs into spaces is obviously a Fish bug, IMHO... (Neither of
>> bash's modes (with quotes, or without them) match this fish behavior)
>>
> Fish intentionally does NOT conform to bash's space handling, it tries
> to do better.
> [[command-substitutions]] fish splits only on newlines, which is
> very useful 95% of the time.
oh my gosh!! I was fooled by Fish's assurance that it would never split
$variable -- not even on newlines -- and indeed it does not. But,
command-substitutions behave differently! I really liked my (apparently
false..) assurances that I'd never need to put quotes around a
substitution just to make it behave differently!
[[ p.s. Beni later reminds me that $arrayvar behaves differently inside
quotes... the behaviour of generating spaces implicitly as the separator
never satisfied me in that case, and I just pretend you can't substitute
arrays inside quotes, because what, conceptually, does it mean? (in-fact
I have to resort to Bash to print the "true" value of the PATH variable,
which most definitely uses colons :-) ]]
(incidentally, in bash, you can change the space-expansion handling by
changing IFS -- splitting only on newlines, and not splitting on
anything at all, are options. Hmm, I never thought of the idea of
setting IFS in my .bashrc to change the bash interactive experience..hmm!)
(ideally, I'd think an annotation about how you wanted an expansion to
be split would be best placed on the expansion (or maybe on the whole
word-to-be-split). But then syntax would have to be invented... for
(bad) example: $[split=space]variable
> IMHO all other expansions ("%process", "~user homedir",
> "{brace,expansion}", "even *wildcards*?") should work too. This is
> not what other shells do, but it's useful:
>
> - File paths with a lot of spaces are cumbersome unless you use quotes.
> Globbing such paths inside double quotes would be nice.
hmm, that's true. On the other hand, file paths with a lot of characters
like * then become more cumbersome. So why not use single-quotes? : My
filenames also sometimes contain ' (apostrophe/single-quote), which
makes it annoying to use single-quoting even when you didn't need any
expansions (some of my music files do or did contain apostrophes... also
parentheses... actually, I am zealous enough to replace all the spaces
and some of the weird characters with underscores, but I don't think
most people are, and until now I still have parentheses and apostrophes
because they've been safe enough to use...)
> - Brace expansion is mostly interesting for the "foo{$var}bar" pattern.
> - "~user" and "%process" are less useful, and sometimes annoying.
> But I'd include them for consistency.
> I think the consistency argument wins: the "all expansions work in
> double quotes" rule is trivial to remember, anything else isn't.
it might also make me ramp up my efforts to leave fish... although on
the flip side, things would be much better if I could type directional
quotes in order to quote things in the shell, so that quoting quotes
wouldn't be such a nuisance (obstacles include, minor: parsing it, and
major: keyboards don't let you type anything resembling directional
quotes very directly.)
I'm willing to entertain the merits of letting expansions inside
double-quotes, but not without resolving the issue of whether Fish
should ever treat expansions differently (in the cases that it expands
them at all) inside and outside quotes. It doesn't, currently--(correct
me if I'm wrong).
-Isaac
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
