On 2/21/06, James Antill <[EMAIL PROTECTED]> wrote:
> "Axel Liljencrantz" <[EMAIL PROTECTED]> writes:
>
> > Feels like I'm repeating myself a bit here, but welcome back, James.
> > Long time since your last post! :-)
>
> We're all just a bunch of I lurkers :)
That's fine. My ego interprets silence as implicit agreement with
whatever stupid thing I'm currently advocating. ;)
>
> > On 2/20/06, James Antill <[EMAIL PROTECTED]> wrote:
> >> "Axel Liljencrantz" <[EMAIL PROTECTED]> writes:
> >>
> >> > Welcome back, John. Long time since your last post!
> >> >
> >> > On 2/18/06, John Brock <[EMAIL PROTECTED]> wrote:
> >> >> John Brock
> >> >> [EMAIL PROTECTED]
> >> >>
> >> >> On Fri, Feb 17, 2006 at 07:05:19PM -0500, Philip Ganchev wrote:
> >> >> > I dislike this because it is impossible to tell if a newline is
> >> >> > escaped or if one is escaping a space character. Though I've thought
> >> >> > about this for a bit and have come to the conclusion that this is an
> >> >> > editor issue. An editor could, if it wanted to, differentiatte between
> >> >> > the two, for example by highlighting the backslashed newline using a
> >> >> > different background color.
> >> >> >
> >> >> > I guess an otherwise rather sane syntax should not be punished because
> >> >> > editors are stupid.
> >>
> >> A much bigger problem IMO is that fish doesn't parse \\, and to add
> >> compatibility you'd basically need a full \ parser (you'd at least
> >> need to understand \ EOL and \\, at which point you might as well add
> >> \n \t \b \r \0xx \xxx etc.).
> >
> > ?
> >
> > Fish _does_ have a \ parser. \n, \t, \\ and friends all work, as do
> > \$, \{, \% \(, and other characters used for argument expansion. Fish
> > even supports \xXX, \oOOO, \uXXXX, etc for arbitrary symbols, e.g.
> > 'echo \u2026' writes out an unicode ellipsis character to stdout.
>
> Ahh, I had tried it with quotes Ie. "a\nb" and even "a\"b" (which is
> a syntax error) ... and tr does \ processing itself, so I just assumed
> the rest.
Yes, it may seem a bit counter intuitive to allow \n but not '\n', but
once you start thinking about it, the role of quotes in shellscript
languages are to _remove_ various types of argument expansion, not to
add new ones. And from that perspective, I really think the fish
syntax makes perfect sense. And it sure beats the braindead $'\n'
syntax used in other shells.
>
> > Actually, though, one of the above _is_ missing, namely \0. Fish
> > internally uses null-terminated strings, it would take a bit of work
> > to handle \0 correctly, though I suppose that this should be done.
>
> http://www.and.org/vstr/security ;)
You wrote that? Very nice page. In my defense I will say these things:
* When I started writing fish, I couldn't find any good dynamic string
library using wchar_t. This is also why fish uses it's own internal
tokenizer instead of something like flex.
* I have since started to use a very simplistic internal set of string
functions in fish, that don't rely on zero-terminating strings. I hope
to eventually switch all internal fish code to use this library, but
I'm doing it one place at a time.
>
> Also note that \000 is just the normal octal encoding though,
> Ie. from the tr man page:
>
> \NNN character with octal value NNN (1 to 3 octal digits)
I had no idea. Though I must say that 'normal' depends on where you
are coming from. tr (and probably many other commands/languages) use
\NNN, while Python, C and a host of other computer languages use
\oOOO. Since I didn't know about the tr syntax, I went with what was
familiar to me, i.e. \oOOO. I think this feature is used rarely enough
that it should be ok to change it, so the question is - which syntax
is better? On one hand, tr is more likely to be used in combination
with fish, but on the other hand, \oOOO seeems more logical when
considering that \xXX, \uXXXX and \UXXXXXXXX also exist.
>
> >> Also, personally, I don't see:
> >>
> >> echo a |; cat
> >>
> >> ...as anymore weird than:
> >>
> >> echo a ;;; ;;; echo b
> >
> > The way I see it, (and the way fish currently sees it,
> > implementation-wise) is that a newline is exactly equivalent to a ';'.
> > The tokenizer (fish uses an internally implemented tokenizer since
> > there is (was?) no flex-lookalike with support for wchar_t) returns
> > exactly the same symbol for both, TOK_END, when either of these is
> > encountered in an unquoted context. I think that this is a very sane,
> > simple and intuitive way to look at things.
> >
> > The above code example is, as fish sees it, equivalent to
>
> I think there's a mis-communication ... I wasn't implying that the
> above should be removed but that given it does work I see no reason to
> disallow |; (both work in zsh, and I've never seen people use them
> ... if that helps).
I guess this comes down to a difference in how one sees | vs. ;. I see
them as operators working on the same level, i.e. means '|' end the
process definition but not the job definition, while ';' means end the
current job definition.
>From that point of view, ';;;' is a set of 'empty commands' i.e.
commands that result in no actions, while 'foo|;' is a command whose
output should be piped into the empty command. It should be noted here
that some other languages, including C, also have this notion of an
'empty statement', and that they are allowed in most places in stead
of a regular statement, but not everywhere. With my limited
imagination, piping something to 'the empty command' seems like pure
nonsense. The only reasonable interpretation, from my view, is that
the empty command is a command that accepts any input and does nothing
with it, and when exiting doesn't change the exit status flag. But
that is not the suggested behaviour. Instead, it is suggested that
when a ';' is encountered following a '|', the ';' should be ignored.
I'm curious to how others see the the interaction between ';' and '|',
if anyone can explan to me their view on how they should be
interpreted, I'm all ears.
>
> >> >> So why
> >> >> not just make it the rule that fish discards all whitespace at the
> >> >> end of a line (unless you are inside a quote or something)?
> >>
> >> Which would make it's behaviour different from anything else that
> >> does \ processing.
> >>
> >> > That is an interesting idea. The benefits you outline above are
> >> > desirable. The result is however somewhat unintuitive in other cases.
> >> > Say that you want to replace all tabs in the output of grep with
> >> > spaces. An easy way to do this would be:
> >> >
> >> > grep WHATEVER | tr \t \
> >>
> >> Even better is:
> >>
> >> foo | tr \t\ \\\
> >
> > I'm missing something here. How is this better and what would this do?
>
> It's a better example of something bad, to see it one token (roughly)
> per line:
>
> "foo"
> "|"
> "tr"
> "\t\ "
> "\\\ "
> EOL
>
> ...here the final "\\\ " would be treated as a single \ and the
> previous "\t\ " would be treated as a tab followed by a space
Ah, ok. This is not the most easily described of syntax issues...
>
> --
> James Antill -- [EMAIL PROTECTED]
> http://www.and.org/and-httpd
>
--
Axel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Fish-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fish-users
