Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

Hi everybody,

This is mostly a copy of [a question already posted on 
stackoverflow](https://stackoverflow.com/questions/48006335/can-zsh-else-reserved-keyword-command-be-aliased-and-the-lexem-itself-be-repur). 
Maybe it might have more chance to get an answer over here.

# The problem

Following [ZSH: Call in-built function from zsh function that uses the 
same 
name](https://stackoverflow.com/questions/37498409/zsh-call-in-built-function-from-zsh-function-that-uses-the-same-name) 
and [Run a command that is shadowed by an 
alias](https://unix.stackexchange.com/questions/39291/run-a-command-that-is-shadowed-by-an-alias#39296), 
it might be expected that a command `keyword` equivalent of what 
`builtin` and `command` are doing for their respective eponymous token 
category; so that

     if [ -z 'love' ]; then echo 'sad world'; keyword else echo 
'wonderful world'; fi

would be equivalent to

     if [ -z 'love' ]; then echo 'sad world'; else echo 'wonderful 
world'; fi

This problem was found in the following tricky scenario: being able to 
replace `else` with `alie` and `fi` with `else`. See [Can zsh buildtins 
be 
aliased?](https://stackoverflow.com/questions/47999451/can-zsh-buildtins-be-aliased) 
for more details.

So an hypothetical attempt to implement that, if the `keyword` command 
existed, would be:

   alias alie="keyword else"
   alias else='fi'

# Summary

So, to sum it up, the question is how do you make the following peace of 
zsh code works as expected by the previous command:

     if [ -z 'love' ]; then echo 'sad world'; alie echo 'wonderful 
world'; else

# A first trail

This is not yet a working solution, but here is an idea: using the `-r` 
flag of `enable` and `disable` builtin commands to change visibility of 
the `else` keyword. So:

     alias se='enable -r else; if'
     alias alie='else'
     disable -r else
     alias else="fi; disable -r else"

This unfortunately doesn't work

     se [ -z 'amo' ]; then echo 'trista mondo'; alie echo 'mirinda 
mondo'; else
     # zsh: parse error near `fi'

This is however supposedly on the "else" alias substitution that 
something break, as a non-inline version will indeed enter the 
else-branch and print "mirinda mondo".

Kind regards

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]

On a side note, the line `enable -r else; if true; then else fi; disable 
-r else` won't work with two execution in a row:

      ▶ enable -r else; if true; then else fi; disable -r else # works
      ▶ export LANC=C enable -r else; if true; then else fi; disable -r else
      fi # added to close the `if`
      => export: not valid in this context: -r

Is there a way to force execution at some point on a single line, as if 
there was performed on two lines?


Le 28/12/2017 à 16:07, mathieu stumpf guntz a écrit :
> Hi everybody,
>
> This is mostly a copy of [a question already posted on 
> stackoverflow](https://stackoverflow.com/questions/48006335/can-zsh-else-reserved-keyword-command-be-aliased-and-the-lexem-itself-be-repur). 
> Maybe it might have more chance to get an answer over here.
>
> # The problem
>
> Following [ZSH: Call in-built function from zsh function that uses the 
> same 
> name](https://stackoverflow.com/questions/37498409/zsh-call-in-built-function-from-zsh-function-that-uses-the-same-name) 
> and [Run a command that is shadowed by an 
> alias](https://unix.stackexchange.com/questions/39291/run-a-command-that-is-shadowed-by-an-alias#39296), 
> it might be expected that a command `keyword` equivalent of what 
> `builtin` and `command` are doing for their respective eponymous token 
> category; so that
>
>     if [ -z 'love' ]; then echo 'sad world'; keyword else echo 
> 'wonderful world'; fi
>
> would be equivalent to
>
>     if [ -z 'love' ]; then echo 'sad world'; else echo 'wonderful 
> world'; fi
>
> This problem was found in the following tricky scenario: being able to 
> replace `else` with `alie` and `fi` with `else`. See [Can zsh 
> buildtins be 
> aliased?](https://stackoverflow.com/questions/47999451/can-zsh-buildtins-be-aliased) 
> for more details.
>
> So an hypothetical attempt to implement that, if the `keyword` command 
> existed, would be:
>
>   alias alie="keyword else"
>   alias else='fi'
>
> # Summary
>
> So, to sum it up, the question is how do you make the following peace 
> of zsh code works as expected by the previous command:
>
>     if [ -z 'love' ]; then echo 'sad world'; alie echo 'wonderful 
> world'; else
>
> # A first trail
>
> This is not yet a working solution, but here is an idea: using the 
> `-r` flag of `enable` and `disable` builtin commands to change 
> visibility of the `else` keyword. So:
>
>     alias se='enable -r else; if'
>     alias alie='else'
>     disable -r else
>     alias else="fi; disable -r else"
>
> This unfortunately doesn't work
>
>     se [ -z 'amo' ]; then echo 'trista mondo'; alie echo 'mirinda 
> mondo'; else
>     # zsh: parse error near `fi'
>
> This is however supposedly on the "else" alias substitution that 
> something break, as a non-inline version will indeed enter the 
> else-branch and print "mirinda mondo".
>
> Kind regards
>
>

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Thu, Dec 28, 2017 at 7:19 AM, mathieu stumpf guntz
<psychoslave@culture-libre.org> wrote:
>
>      ▶ export LANC=C enable -r else; if true; then else fi; disable -r else

You're missing a semicolon after the "C".  That's the reason you get

>      => export: not valid in this context: -r


> Is there a way to force execution at some point on a single line, as if
> there was performed on two lines?

If I understand your question, the answer is "no": you can't execute
the front part of an "if" until the "fi" has been read.  See my
previous email "fully parsed before executed."

(Well, you could switch to csh, which does execute every line as it
goes along, even in complex structures.  But no, not in zsh.)

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 1549 bytes --]



Le 29/12/2017 à 09:47, Bart Schaefer a écrit :
> You're missing a semicolon after the "C". That's the reason you get 
Thank you. For some reason however, the seconde run of `export LANC=C; 
enable -r else; if true; then echo 'yep'; else echo 'nop'; fi; disable 
-r else` will return an error message with the system local anyway:

    % enable -r else;
    % export LANC=C; enable -r else; if true; then echo 'yep'; else echo
    'nop'; fi; disable -r else
    yep
    % export LANC=C; enable -r else; if true; then echo 'yep'; else echo
    'nop'; fi; disable -r else
    yep
    zsh: else: commande inconnue.

> If I understand your question, the answer is "no": you can't execute
> the front part of an "if" until the "fi" has been read.  See my
> previous email "fully parsed before executed."
I'm rather estonished by this lake of possibility to make the equivalent 
of an "\n" in the middle of a line, but OK.

So the idea would be to have something like

    % whence -w else
    else: reserved
    % enable -r else; "\n" whence -w else; if true; then echo 'yep';
    else echo 'nop'; fi; disable -r else
    else: reserved
    yep
    % whence -w else
    else: none
    % enable -r else; "\n" whence -w else; if true; then echo 'yep';
    else echo 'nop'; fi; disable -r else
    else: reserved
    yep

But "\n" doesn't work here as a substitution of an effective linefeed.
> (Well, you could switch to csh, which does execute every line as it
> goes along, even in complex structures.  But no, not in zsh.)
Nice to know, thank you.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Fri, Dec 29, 2017 at 2:51 AM, mathieu stumpf guntz
<psychoslave@culture-libre.org> wrote:
>
> I'm rather estonished by this lake of possibility to make the equivalent of
> an "\n" in the middle of a line, but OK.

Shell language is a programming language.  Do you know any other
programming languages?  Do you find it astonishing that you can't
execute an incomplete C or Java program?

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

Le 29/12/2017 à 20:15, Bart Schaefer a écrit :

> Shell language is a programming language.  Do you know any other
> programming languages?  Do you find it astonishing that you can't
> execute an incomplete C or Java program?
The question is not to know if the interpreter can execute an incomplete 
program. The point is to send a signal to the interpreter which order to 
interrupt usual parsing and try to interpret what was already buffered 
right now. Of course it can fails. But a program interpretation can fail 
even when "it is complete".

On a side humoristic note, one might perfectly imagine an interpreter 
that try to infer realistic expectation, or more simply associate a 
valid program to any random input. ;)

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Fri, Dec 29, 2017 at 11:29 AM, mathieu stumpf guntz
<psychoslave@culture-libre.org> wrote:
>
> The question is not to know if the interpreter can execute an incomplete
> program. The point is to send a signal to the interpreter which order to
> interrupt usual parsing and try to interpret what was already buffered right
> now.

Of course from the command line (as opposed to when reading a script
file) that *is* what happened.  However, the result of "try to
interpret" was "oh, this isn't complete yet, I need to ask for the
rest".

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

On 29/12/17 11:49 AM, Bart Schaefer wrote:
> On Fri, Dec 29, 2017 at 11:29 AM, mathieu stumpf guntz
> <psychoslave@culture-libre.org> wrote:
>> The question is not to know if the interpreter can execute an incomplete
>> program. The point is to send a signal to the interpreter which order to
>> interrupt usual parsing and try to interpret what was already buffered right
>> now.
> Of course from the command line (as opposed to when reading a script
> file) that *is* what happened.  However, the result of "try to
> interpret" was "oh, this isn't complete yet, I need to ask for the
> rest".
>
As for me, the very idea that a reserved word could be aliased seems 
monstrous. In any information system there must be tokens who's meaning 
is absolute.  How you guys can begin to make it possible to parse such 
things is beyond me, it seems like black magic.  But I am curious, what 
does it mean to say that an interpreted program is incomplete?  I mean, 
unclosed quotes and such things are clearly incomplete, but other than that?

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Fri, Dec 29, 2017 at 12:27 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> As for me, the very idea that a reserved word could be aliased seems
> monstrous.

If  you realize that aliasing is mostly analogous to #define in
C-and-friends, this becomes less horrifying.  It's little more than a
built-in preprocessor.

> But I am curious, what does it
> mean to say that an interpreted program is incomplete?

In this case it means any unfinished complex code structure -- "if"
without "fi", "do" without "done", "case" without "esac", "foreach"
without "end".  Mathieu wants execution to begin as soon as there is
some code in the buffer, without waiting for the final keyword to
appear.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Fri, Dec 29, 2017 at 3:45 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> Mathieu wants execution to begin as soon as there is
> some code in the buffer, without waiting for the final keyword to
> appear.

Not-so-incidentally, the fact that zsh does NOT do this is one of the
primary reasons that zsh exists at all.  Paul Falstad found it
distasteful that csh DOES that, and set out to create a shell that had
the interactive advantages of csh while preserving the separation of
parse and execution as found in sh and ksh.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]


Le 30/12/2017 à 02:07, Bart Schaefer a écrit :
> On Fri, Dec 29, 2017 at 3:45 PM, Bart Schaefer
> <schaefer@brasslantern.com> wrote:
>> Mathieu wants execution to begin as soon as there is
>> some code in the buffer, without waiting for the final keyword to
>> appear.
Where odes this quote come from, it seems I missed a message. Did 
someone replied to "zsh-workers@"?

> Not-so-incidentally, the fact that zsh does NOT do this is one of the
> primary reasons that zsh exists at all.  Paul Falstad found it
> distasteful that csh DOES that, and set out to create a shell that had
> the interactive advantages of csh while preserving the separation of
> parse and execution as found in sh and ksh.
I was, of course, completely unaware of that. I would be interested with 
more technical details if you could provide me some links.

And, just for memory, forcing execution at some explicit point is not my 
goal, but just a possible mean I considered to bypass the lake of a 
"keyword" reserved-keyword-command, similar to `command` and `builtin`. 
Implenting such a thing wouldn't require de abandon the separation of 
parse and execution, would it?

Cheers

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Frank Terbeck]

Hi.

mathieu stumpf guntz wrote:
> Le 30/12/2017 à 02:07, Bart Schaefer a écrit :
[...]
>> Not-so-incidentally, the fact that zsh does NOT do this is one of the
>> primary reasons that zsh exists at all.  Paul Falstad found it
>> distasteful that csh DOES that, and set out to create a shell that had
>> the interactive advantages of csh while preserving the separation of
>> parse and execution as found in sh and ksh.
>
> I was, of course, completely unaware of that. I would be interested with more
> technical details if you could provide me some links.

There's a fairly well known explanation of this, which can be found if
you look for "CSH Programming Considered Harmful". It's archived in
multiple places, for example here:

  http://harmful.cat-v.org/software/csh

It discusses a lot of csh deficiencies, its ad-hoc parser being one of
them.


Regards, Frank
-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

On 29/12/17 05:07 PM, Bart Schaefer wrote:
> On Fri, Dec 29, 2017 at 3:45 PM, Bart Schaefer
> <schaefer@brasslantern.com> wrote:
>> Mathieu wants execution to begin as soon as there is
>> some code in the buffer, without waiting for the final keyword to
>> appear.
> Not-so-incidentally, the fact that zsh does NOT do this is one of the
> primary reasons that zsh exists at all.  Paul Falstad found it
> distasteful that csh DOES that, and set out to create a shell that had
> the interactive advantages of csh while preserving the separation of
> parse and execution as found in sh and ksh.
>
Cool!  These insights from history are so very illuminating.  Mind ... 
that would seem to make it all the more possible/acceptable to do what 
Mathieu wants, it'd be a compatibility featurenot some sort of 
abominable novelty the way my suggestions are abominable novelties.


setopt csh_parsing ?

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Sat, Dec 30, 2017 at 9:22 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> Cool!  These insights from history are so very illuminating.  Mind ... that
> would seem to make it all the more possible/acceptable to do what Mathieu
> wants, it'd be a compatibility feature not some sort of abominable novelty
> the way my suggestions are abominable novelties.

It would still be pretty abominable.  Every loop structure would need
two implementations, the current one and the "csh" one, because if you
execute as you parse you can't keep the parse around for re-use -- you
have to store all the original text and re-parse it again the next
time.  Some csh implementations put the text in a hidden file and use
lseek() to move back and forth in the file for looping.  For scripts
they just use the original source file!  (I've written self-modifying
csh scripts by taking advantage of this.)

You really don't want to go there.

If you're desperate to experience something like this, you can get
close in an interactive shell by having accept-line call "eval" on the
buffer and then deciding what to do next based on the results.  It'd
be a bit tricky to retain what's already been processed once so you
know whether/when to eval it again, but something could probably be
worked out.  I'm not going to try.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

On 30/12/17 02:06 PM, Bart Schaefer wrote:
>
> You really don't want to go there.
>
> If you're desperate to experience something like this,

Heck no, not me, I'm just interested in the zen of the idea.  And you've 
already said enough for me to understand that some naive idea about a 
'csh' mode is a nonstarter.

Yabut, what about some sort of auto-ending of code structures? Even if 
parsing was by exactly the same non-csh method, would it not be possible 
to turn off the code checker and just sorta run until the tracks stop at 
which point the thing returns?

     if [ something ]; then blah

     elif [something_else]; then foo

... and it just stops there not worrying about the fact that 'fi' is 
missing.

Or, does the zsh parsing system really forbid such a thing? True, it 
would know about the issue at the parse and before execution even 
begins, but could it not just 'presume' the 'fi'? Sorta like the fact 
that I should close the door after I leave, but it is possible for me to 
depart and leave the door open. Mind, this could only even theoretically 
apply to code that is missing closings at the very end of itself.  Maybe 
easier to imagine than to implement, and certainly rather strange.  
Never mind, I'm just curious.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

On 29/12/17 03:45 PM, Bart Schaefer wrote:
>
> If  you realize that aliasing is mostly analogous to #define in
> C-and-friends, this becomes less horrifying.  It's little more than a
> built-in preprocessor.

When you put it that way, yes, the horror diminishes ... just so long as 
no anarchist tries to redefine 'alias' or some such thing. There HAS to 
be something who's meaning is not negotiable.

   #define define "undefine"
   #define undefine "define"
   alias alias="this must surely be forbidden"

I dunno, maybe there are reasons to want to fiddle with reserved words 
but it seems blasphemous to me.  Never mind.
>
>> But I am curious, what does it
>> mean to say that an interpreted program is incomplete?
> In this case it means any unfinished complex code structure -- "if"
> without "fi", "do" without "done", "case" without "esac", "foreach"
> without "end".  Mathieu wants execution to begin as soon as there is
> some code in the buffer, without waiting for the final keyword to
> appear.
>
I see.  Well, just for my education, why would that be impossible?  The 
protections zsh offers us against unfinished code are obviously helpful 
virtually always, but since we are interpreting, would it not be 
possible to just sorta turn those protections off and march blindly 
ahead executing each line in turn until the cliff is reached and some 
sort of crash happens? I'd expect the shell would have to crash at that 
point, or maybe there could be some kind of graceful auto-return, with a 
sort of presumptive close of all open grammars so that no feathers are 
ruffled.  But I'd expect such a thing should be doable, strange as it 
seems to want it.  Would that not be what would have happened in the 
early days before code checking was implemented?


   setopt crash_and_burn ?

   setopt press_on_regardless ?

   setopt close_everything_magically ?

   setopt 
no_code_checking_we_warned_you_not_to_do_this_but__did_you_listen ?  ;-)

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]



Le 30/12/2017 à 18:16, Ray Andrews a écrit :
>
> When you put it that way, yes, the horror diminishes ... just so long 
> as no anarchist tries to redefine 'alias' or some such thing. There 
> HAS to be something who's meaning is not negotiable.
>
>   #define define "undefine"
>   #define undefine "define"
>   alias alias="this must surely be forbidden"

There are only a few things that must be intepreted in a clearly defined 
consensual way for a very limited and well specified context.

By the way, "alias" in Esperanto means "is other than" and as such would 
certainly make a great keyword for the inequality operator. :)

>
> I dunno, maybe there are reasons to want to fiddle with reserved words 
> but it seems blasphemous to me.  Never mind.
Uttering some blasphemes might be a strong motivational per se. :)

But to give a broader context this is in fact investigated as part of 
this wikiversity research project about internationalisation of 
programming languages: 
https://en.wikiversity.org/wiki/Internationalisation_of_Programming_Languages

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 614 bytes --]

On 30/12/17 02:23 PM, mathieu stumpf guntz wrote:
>
>> #define define "undefine"
>>   #define undefine "define"
>>   alias alias="this must surely be forbidden"
>
> There are only a few things that must be intepreted in a clearly 
> defined consensual way for a very limited and well specified context.

Do we have a list of these?
>
> But to give a broader context this is in fact investigated as part of 
> this wikiversity research project about internationalisation of 
> programming languages: 
> https://en.wikiversity.org/wiki/Internationalisation_of_Programming_Languages
>
Thanks, that's interesting.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]



Le 31/12/2017 à 00:06, Ray Andrews a écrit :
> On 30/12/17 02:23 PM, mathieu stumpf guntz wrote:
>>
>>> #define define "undefine"
>>>   #define undefine "define"
>>>   alias alias="this must surely be forbidden"
>>
>> There are only a few things that must be intepreted in a clearly 
>> defined consensual way for a very limited and well specified context.
>
> Do we have a list of these?
I guess there is a formal definition of the zsh grammar somewhere, like 
an EBNF or something. Then that is the consensus on top on which you can 
build anything that is not unparsable according to that grammar. And zsh 
most probably is TuringComplete so basically you might build anything 
with it, including a parser for an other programming language. But the 
important thing for the internationalisation research underlying this 
experimentation is "how much can you localise the programming interface 
in an integrated way, that is how much the localised version works (and 
bugs) as the non-localised version?"

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 876 bytes --]

Hi Ray,

Le 29/12/2017 à 21:27, Ray Andrews a écrit :
> As for me, the very idea that a reserved word could be aliased seems 
> monstrous. In any information system there must be tokens who's 
> meaning is absolute.  How you guys can begin to make it possible to 
> parse such things is beyond me, it seems like black magic.
Our monstrous black spells will turn all your beliefs in absolute 
relativity, thou mere creature of flesh. ;)
> But I am curious, what does it mean to say that an interpreted program 
> is incomplete?  I mean, unclosed quotes and such things are clearly 
> incomplete, but other than that?
Well, any peace of code which can not, through a given grammar, be 
turned into an actual set of instructions which once run will either 
terminate or run for an undetermined period. Of course this is a rather 
sparse explanation :)

Witchly,
psychoslave

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Ray Andrews]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On 30/12/17 01:36 AM, mathieu stumpf guntz wrote:
> Hi Ray,
>
> Le 29/12/2017 à 21:27, Ray Andrews a écrit :
>> As for me, the very idea that a reserved word could be aliased seems 
>> monstrous. In any information system there must be tokens who's 
>> meaning is absolute.  How you guys can begin to make it possible to 
>> parse such things is beyond me, it seems like black magic.
> Our monstrous black spells will turn all your beliefs in absolute 
> relativity, thou mere creature of flesh. ;)

Ha!  Yes, I fear the dark, yet sometimes tread where angels will not go.



https://www.youtube.com/watch?v=Xg54VULakes

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Nikolay Aleksandrovich Pavlov (ZyX)]

29.12.2017, 13:53, "mathieu stumpf guntz" <psychoslave@culture-libre.org>:
> Le 29/12/2017 à 09:47, Bart Schaefer a écrit :
>>  You're missing a semicolon after the "C". That's the reason you get
>
> Thank you. For some reason however, the seconde run of `export LANC=C;
> enable -r else; if true; then echo 'yep'; else echo 'nop'; fi; disable
> -r else` will return an error message with the system local anyway:
>
>     % enable -r else;
>     % export LANC=C; enable -r else; if true; then echo 'yep'; else echo
>     'nop'; fi; disable -r else
>     yep
>     % export LANC=C; enable -r else; if true; then echo 'yep'; else echo
>     'nop'; fi; disable -r else
>     yep
>     zsh: else: commande inconnue.
>
>>  If I understand your question, the answer is "no": you can't execute
>>  the front part of an "if" until the "fi" has been read. See my
>>  previous email "fully parsed before executed."
>
> I'm rather estonished by this lake of possibility to make the equivalent
> of an "\n" in the middle of a line, but OK.
>
> So the idea would be to have something like
>
>     % whence -w else
>     else: reserved
>     % enable -r else; "\n" whence -w else; if true; then echo 'yep';
>     else echo 'nop'; fi; disable -r else
>     else: reserved
>     yep
>     % whence -w else
>     else: none
>     % enable -r else; "\n" whence -w else; if true; then echo 'yep';
>     else echo 'nop'; fi; disable -r else
>     else: reserved
>     yep
>
> But "\n" doesn't work here as a substitution of an effective linefeed.
>>  (Well, you could switch to csh, which does execute every line as it
>>  goes along, even in complex structures. But no, not in zsh.)
>
> Nice to know, thank you.

If you do not like any part of shell syntax, want to use ZLE for Python REPL or whatever there is a thing which 100% works: just override accept-line widget and have zshaddhistory hook to put original line into history. For example I am using the following to have more extensive escaping for `:h`, `zmw` and `zpy` “commands”:

    function zshaddhistory()
    {
        emulate -L zsh
        if (( ${+_HISTLINE} && ${#_HISTLINE} )) ; then
            print -sr -- "${_HISTLINE}"
            unset _HISTLINE
        elif (( 0x20==#1 )) ; then
            return 1
        elif (( ${#1} )) ; then
            print -sr -- "${1%%$'\n'}"
        fi
        fc -p
    }
    function _-accept-line()
    {
        emulate -L zsh
        local -r autopushd=${options[autopushd]}
        options[autopushd]=off
        cd $PWD || cd
        options[autopushd]=$autopushd
        if [[ ${BUFFER[1,3]} == ":h " ]] ; then
            typeset -g _HISTLINE=$BUFFER
            BUFFER=":h ${(q)BUFFER[4,-1]}"
        elif [[ ${BUFFER[1,4]} == "zmw " ]] ; then
            typeset -g _HISTLINE=$BUFFER
            BUFFER="zmw "${(j. .)${(q)${(z)BUFFER[5,-1]}}}
        elif [[ ${BUFFER[1,4]} == "zpy " ]] ; then
            typeset -g _HISTLINE=$BUFFER
            BUFFER="zpython ${(qqq)BUFFER[5,-1]}"
        fi
        zle .accept-line
    }
    zle -N accept-line                       _-accept-line

The main problem with this approach is that you will have to do more parsing yourself then you probably preferred to have to do though.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[Bart Schaefer]

On Thu, Dec 28, 2017 at 7:07 AM, mathieu stumpf guntz
<mathieu.stumpf-guntz@epopia.com> wrote:
> it might be expected that a command `keyword` equivalent of what `builtin`
> and `command` are doing for their respective eponymous token category

If you haven't already, go read https://askubuntu.com/a/590335 which
was linked from
https://stackoverflow.com/questions/47999451/can-zsh-buildtins-be-aliased

Your hypothetical "keyword" would have to itself be a keyword (and
thus not a command).

> This problem was found in the following tricky scenario: being able to
> replace `else` with `alie` and `fi` with `else`.
[...]
>   alias alie="keyword else"
>   alias else='fi'

What's the underlying reason for doing this?  That is, aside from the
overall desire to write in Esperanto (?),  I get wanting "alie" to
mean the same thing "else" means, but not why "else" should mean "fi".
Even in your "alie echo 'mirinda mondo'"  example it looks like "else"
is meant to act as "fi;else" so that you can continue with more of the
sentence.

> This is not yet a working solution, but here is an idea: using the `-r` flag
> of `enable` and `disable` builtin commands to change visibility of the
> `else` keyword

This is doomed to failure, because complex shell syntax is fully
parsed before it is executed.  Your "disable" or "enable" has to take
place before the parsing step, because it won't be executed during the
parse.  Some extremely simple cases might appear to work at the
command prompt, but as soon as you embed them in a larger structure
like a function body they will fail.

In fact the "fully parsed before executed" property is one of the
important reasons for keywords being distinct from commands.

Aliases "work" before the parse because they are merely text
replacements and can be done before full token analysis is performed.

What is needed is an alias that ends recursive replacement.  Normally
one does this by including quoting (e.g., a leading backslash) in the
value of the alias, but that doesn't help in this case because it
prevents the replacement from being considered a keyword as well.
There may be a clever way to accomplish this -- recursion stops if
replacement results in a previously replaced alias, for example, to
avoid infinite loop -- but I haven't worked out an answer.

Re: Can zsh `else` reserved keyword command be aliased and the lexem itself be repurposed as `fi` keyword command?

[mathieu stumpf guntz]

[-- Attachment #1: Type: text/plain, Size: 4235 bytes --]

Hello Bart,

First, thank you for having taken some time to write this detailed answer.


Le 29/12/2017 à 09:38, Bart Schaefer a écrit :
> If you haven't already, go read https://askubuntu.com/a/590335 which
> was linked from
> https://stackoverflow.com/questions/47999451/can-zsh-buildtins-be-aliased
>
> Your hypothetical "keyword" would have to itself be a keyword (and
> thus not a command).
Yes, I had red it, and I even took time to read it again in case I 
missed something, but I didn't find what. Actually, it says "aliases can 
be used to alias keywords!", so it made me more confident about the fact 
that it might be possible.

I understand that the hypothetical "keyword" callable-stuff should be of 
type keyword however (however it's tricky to make clear sentences about 
such an intricated topic). I don't have in mind the whole interpretation 
pipeline in mind, an [acitivity 
diagram](http://plantuml.com/activity-diagram-beta) would be welcome 
here. However, it does  make  sense that the tool to make a substitution 
at some level must be at least at the same type level or in a type which 
is interpreted earlier.

> What's the underlying reason for doing this?
Admitedly, it's an interesting challenge which enable to grab a little 
more knowledge on the shell.
>   That is, aside from the
> overall desire to write in Esperanto (?),  I get wanting "alie" to
> mean the same thing "else" means, but not why "else" should mean "fi".
Because "else" could litteraly be translated "out of if". Maybe [12.3.2 
Directional prepositions / Grammar - 
lernu.net](https://lernu.net/en/gramatiko/direktaj_prepozicioj) can give 
a good grab on this. And Esperanto is an agglutinate language, you can 
concatenate any set of lexemes and it will make sense (most of the 
time). And "el-" as a suffix is common place. But it's difficult to find 
resource in English to appreciate this, the online [plena ilustrita 
vortaro](http://vortaro.net/#el) does give an account of this practice – 
but in Esperanto.

> Even in your "alie echo 'mirinda mondo'"  example it looks like "else"
> is meant to act as "fi;else" so that you can continue with more of the
> sentence.
I'm not sure to understand what you mean here.

But for the sake of the example, you might consider a more complete 
"translation":

    alias se='enable -r else; if'
    alias alie='else'
    disable -r else
    alias else=":fi ; disable -r else"
    alias tiam='then'
    alias ja='['
    alias -g ope=']'
    alias -g plie='-a'
    alias -g vakua='-z'

    alias vera='true'
    alias eĥu='echo'

    se ja vakua $signvico plie vera ope nu tiam # [1]
         eĥu "la signvico estas vakua!"
    alie
         eĥu "la signvico ne estas vakua!"
    else

[1] you might translate that as "if indeed $signvico (is) empty and 
furthermore (it's) true, all that together, well, then…".

In that peace of code, "alie" really is "else", or "otherwise" if you 
prefer.

> This is doomed to failure, because complex shell syntax is fully
> parsed before it is executed.  Your "disable" or "enable" has to take
> place before the parsing step, because it won't be executed during the
> parse.  Some extremely simple cases might appear to work at the
> command prompt, but as soon as you embed them in a larger structure
> like a function body they will fail.
Thus my demand in my other reply, is there a command that say to the 
shell, "ok, stop to eat the stream here and process the chunck of code 
you already buffered so far". As far as I understand, that's what a line 
break usually do. I tried to add one in the alias, including by using a 
heredoc string, but this doesn't work.
> What is needed is an alias that ends recursive replacement.  Normally
> one does this by including quoting (e.g., a leading backslash) in the
> value of the alias, but that doesn't help in this case because it
> prevents the replacement from being considered a keyword as well.
> There may be a clever way to accomplish this -- recursion stops if
> replacement results in a previously replaced alias, for example, to
> avoid infinite loop -- but I haven't worked out an answer.
Well, I stay tune if anyone find any way to solve this challenging goal. ;)

Cheers