On 6/5/08, Isaac Dupree <[EMAIL PROTECTED]> wrote:
>
> in that case I'd rather mention "" (expanded from (echo -n))
> or anyway mention both the value and the expression, for best
> understanding, somehow.
I agree about the principle, but the wording has to be simple.
> BTW. newline is technically a valid filename (at least on my
> filesystem/OS, a normal linux) -- you just don't want it to be!
Well, if Fish disallows it in redirection, it's invalid there. The
error message is correct.
> Anyway, it shouldn't be tokenized, basically: it's a single entity, just
> like a function argument is. And even if the variable expands to '&1',
> it writes to the file named '&1'.
Well, it's treated as a single token, so it's not tokenized. But
tokens don't need to be mentioned.
> fish: Invalid file name "" from (echo -n) for output redirection
That's a bit clumsy as a sentence, and it can be even more confusing
if the offending expression is complicated, like "(obscure_coomand
--option1 --option2 $some_var $other_var)".
> Actually, fish more typically repeats the whole expression and points at
> the troublesome part with a ^, instead of naming the subexpression
That's why I suggested:
fish: Invalid file name "" for output redirection
echo > (echo -n)
^
There is no need to repeat the unexpanded expression in the first sentence.
> inline in the error. (although I'd prefer it to also color the text
> range it's mentioning, which would be easier for the eye to pick out and
> notice, generally)
Yeah, I'd like that too. And if it has to underline, it should
underline the whole token, for example
echo > (echo -n)
^^^^^^^^
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
