Re: why does this define bla() instead of respect the newline as command separator

[Robert Elz]

    Date:        Fri, 19 Mar 2021 17:59:18 +0300
    From:        =?UTF-8?B?T8SfdXo=?= <oguzismailuysal@gmail.com>
    Message-ID:  
<CAH7i3LoCPHSmAwa-k7ukqC9L2FtuH+ar2vo1zribRYVeGnuK5w@mail.gmail.com>


  | Not much related, but isn't this supposed to work?

It is perhaps no surprise (considering their relationship with dash)
that the FreeBSD and NetBSD shells (at least a reasonably up to date
NetBSD sh - aliases used to be an utter mess there) work as well.


  | ksh
  | ksh: syntax error at line 2: `i' unexpected

  | zsh
  | zsh: parse error near `i'
  | zsh: parse error near `i'
  | zsh: parse error near `i'

I have no idea if I'm right or not, but those I can hazard a guess at.

"in" is a peculiar reserved word in sh, it is the one (the only in standard
sh, not sure about those shells that have added reserved words) reserved word
that is never valid in the command word position of a command.  This allows
an implementation to treat it rather differently, looking for it (as "in")
in the couple of places it can occur as a reserved word, rather than doing
a regular reserved word lookup.

If the alias implementation worked as expected this wouldn't matter, as the
"i" would have been translated to "in" before it is seen, but it is possible
that an implementation might look ahead in the input stream, before it has
been tokenised, and hence before alias lookups, to see if the "in" is there
where expected or not.   That would not be correct, but is possible, given
the other aliases defined all worked, but just not that one - and the same
one in 2 different shells (of course, another explanation would be that they
had made "i" a reserved word for some other purpose).

That is, it might be worth doing another test with a sequence that doesn't
use "in" just to see if that works.

kre