zsh-users
 help / color / mirror / Atom feed
* here document within a switch fails to parse.
@ 2021-01-06 15:13 Ray Andrews
  2021-01-06 16:20 ` Daniel Shahaf
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-06 15:13 UTC (permalink / raw)
  To: Zsh Users

function test1 ()
{
: <<'ENDCOM'             # No problems here with either ending #1 or #2
echo "Bad Idea!"         # Some commented code.
ENDCOM                   # Ending #1: comment-out one line ok.
     case ${1} in
         n ) echo en ;;
#: <<'ENDCOM'            # This pair: "parse error near `\n'"
#ENDCOM
     esac
#ENDCOM                  # Ending #2: comment-out most of function ok.
echo "What's goin' on?"
}

... So it seemed that a case statement won't tolerate a here document 
within itself. But then there's this, which parses fine:

function test2 ()
{
     case ${1} in
         n ) echo en ;;

         v )
: <<'ENDCOM'            # But this pair works fine.
            echo "BAD!"  # Some commented code
ENDCOM
            echo GOOD!:  # Much better.
     ;;
     esac
}

... So what am I missing?  Sometimes the here document is perfectly 
ignored, other times it creates an error. Looks wrong. So far I haven't 
found any comparable errors but this.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-06 15:13 here document within a switch fails to parse Ray Andrews
@ 2021-01-06 16:20 ` Daniel Shahaf
  2021-01-06 17:17   ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Daniel Shahaf @ 2021-01-06 16:20 UTC (permalink / raw)
  To: Ray Andrews, Zsh Users

Ray Andrews wrote on Wed, 06 Jan 2021 15:13 +00:00:
> function test1 ()
> {
> : <<'ENDCOM'             # No problems here with either ending #1 or #2
> echo "Bad Idea!"         # Some commented code.
> ENDCOM                   # Ending #1: comment-out one line ok.
>      case ${1} in
>          n ) echo en ;;
> #: <<'ENDCOM'            # This pair: "parse error near `\n'"
> #ENDCOM
>      esac
> #ENDCOM                  # Ending #2: comment-out most of function ok.
> echo "What's goin' on?"
> }
> 
> ... So it seemed that a case statement won't tolerate a here document 
> within itself. But then there's this, which parses fine:
> 
> function test2 ()
> {
>      case ${1} in
>          n ) echo en ;;
> 
>          v )
> : <<'ENDCOM'            # But this pair works fine.
>             echo "BAD!"  # Some commented code
> ENDCOM
>             echo GOOD!:  # Much better.
>      ;;
>      esac
> }
> 
> ... So what am I missing?  Sometimes the here document is perfectly 
> ignored, other times it creates an error. Looks wrong.

The «;;» token must be followed by a pattern, but in your code, it is
followed by a command («:») (which happens to use a heredocument, yes,
but that's not actually relevant:

$ zsh -fc 'case foo in (bar) ;; pwd; esac' 
zsh:1: parse error near `;').

)

> So far I haven't found any comparable errors but this.

Perhaps because many a syntax that look weird are actually valid, but
in any case, here's another place where commands aren't allowed:

repeat foo
bar <<baz
baz
do pwd
done

Cheers,

Daniel


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-06 16:20 ` Daniel Shahaf
@ 2021-01-06 17:17   ` Ray Andrews
  2021-01-06 17:58     ` Lawrence Velázquez
  2021-01-06 19:18     ` Bart Schaefer
  0 siblings, 2 replies; 22+ messages in thread
From: Ray Andrews @ 2021-01-06 17:17 UTC (permalink / raw)
  To: zsh-users

On 2021-01-06 8:20 a.m., Daniel Shahaf wrote:
>
> The «;;» token must be followed by a pattern, but in your code, it is
> followed by a command («:»)
Ok, so at least this is understood.  Still I'd expect the here document 
to be simply removed before parsing.  It's one of those little bits of 
unfriendliness.




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-06 17:17   ` Ray Andrews
@ 2021-01-06 17:58     ` Lawrence Velázquez
  2021-01-06 19:18     ` Bart Schaefer
  1 sibling, 0 replies; 22+ messages in thread
From: Lawrence Velázquez @ 2021-01-06 17:58 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

> On Jan 6, 2021, at 12:17 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> 
>> On 2021-01-06 8:20 a.m., Daniel Shahaf wrote:
>> 
>> The «;;» token must be followed by a pattern, but in your code, it is
>> followed by a command («:»)
> Ok, so at least this is understood.  Still I'd expect the here document to be simply removed before parsing.

A. Why? Here-documents are not comments, despite your best efforts to abuse them for that role.

B. Daniel already demonstrated that your issue has nothing to do with the here-document, but with the presence of the ':' command in an invalid location.

vq
Sent from my iPhone


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-06 17:17   ` Ray Andrews
  2021-01-06 17:58     ` Lawrence Velázquez
@ 2021-01-06 19:18     ` Bart Schaefer
  2021-01-07  7:55       ` Ray Andrews
  1 sibling, 1 reply; 22+ messages in thread
From: Bart Schaefer @ 2021-01-06 19:18 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Wed, Jan 6, 2021 at 9:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> Still I'd expect the here document
> to be simply removed before parsing.

Think again about what you just wrote?

The parser is what determines where the here document begins and ends;
parsing IS what removes it.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-06 19:18     ` Bart Schaefer
@ 2021-01-07  7:55       ` Ray Andrews
  2021-01-07 15:32         ` Daniel Shahaf
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-07  7:55 UTC (permalink / raw)
  To: zsh-users

On 2021-01-06 11:18 a.m., Bart Schaefer wrote:
> On Wed, Jan 6, 2021 at 9:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
>> Still I'd expect the here document
>> to be simply removed before parsing.
> Think again about what you just wrote?
>
> The parser is what determines where the here document begins and ends;
> parsing IS what removes it.
>
Well yes.  I should have said that I'd expect it to be removed at the 
same level that comments are removed. Perhaps as Lawrence says this is 
not a good way to make comment blocks but apart from the one issue 
above, it seems entirely workable.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-07  7:55       ` Ray Andrews
@ 2021-01-07 15:32         ` Daniel Shahaf
  2021-01-07 20:16           ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Daniel Shahaf @ 2021-01-07 15:32 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

Ray Andrews wrote on Wed, Jan 06, 2021 at 23:55:59 -0800:
> On 2021-01-06 11:18 a.m., Bart Schaefer wrote:
> > On Wed, Jan 6, 2021 at 9:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
> > > Still I'd expect the here document
> > > to be simply removed before parsing.
> > Think again about what you just wrote?
> > 
> > The parser is what determines where the here document begins and ends;
> > parsing IS what removes it.
> > 
> Well yes.  I should have said that I'd expect it to be removed at the same
> level that comments are removed. Perhaps as Lawrence says this is not a good
> way to make comment blocks but apart from the one issue above, it seems
> entirely workable.

Do consider treating the language as the independent variable and your
expectations as the dependent one, rather than the other way around.

The syntax means what it means, not what you wish it meant.  Heredocs
are string literals and input redirections, not comments.  They don't
get "removed".  (Just try «:() { nl "$@" }».)

The syntax is stateful.  Heredocs aren't valid everywhere in the shell
grammar, just like the contraction "aren't" aren't valid everywhere in
English grammar.

The construct you use has side-effects you've overlooked, which mean
your fashion of comments will backfire in a way that you don't see yet.
You really should stick to writing idiomatic code.  (-workers@: Ray's
fashion of comments resets lastval.)

Do you see why the error message I quoted upthread complained about the
semicolon and not about something else?  And why «repeat dpkg-query
--list zsh» does what it does?

By the way, I wonder if the reason we're having this thread is that it
hasn't occurred to you that your $EDITOR may have facilities for
commenting or uncommenting multiple lines.

Daniel


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-07 15:32         ` Daniel Shahaf
@ 2021-01-07 20:16           ` Ray Andrews
  2021-01-08 15:27             ` Karsten Borgwaldt
  2021-01-12 13:28             ` Daniel Shahaf
  0 siblings, 2 replies; 22+ messages in thread
From: Ray Andrews @ 2021-01-07 20:16 UTC (permalink / raw)
  To: zsh-users

On 2021-01-07 7:32 a.m., Daniel Shahaf wrote:
> Do consider treating the language as the independent variable and your
> expectations as the dependent one, rather than the other way around.
I'll bend it to my will as much as I can, however 90% of changes since I 
started have been me getting used to zsh rather than the other way 
around.  Still, you don't know what you don't know and however naive, my 
comment blocks do work.   If there's a crash and burn coming up I'm sure 
I'll burn.

>
> The construct you use has side-effects you've overlooked, which mean
> your fashion of comments will backfire in a way that you don't see yet.
I'm prepared to find out the hard way.  Guys like me suffer.
> By the way, I wonder if the reason we're having this thread is that it
> hasn't occurred to you that your $EDITOR may have facilities for
> commenting or uncommenting multiple lines.
There's an interesting idea!  My editor doesn't but that would be quite 
a feature.




^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-07 20:16           ` Ray Andrews
@ 2021-01-08 15:27             ` Karsten Borgwaldt
  2021-01-08 15:53               ` Lawrence Velázquez
  2021-01-12 13:28             ` Daniel Shahaf
  1 sibling, 1 reply; 22+ messages in thread
From: Karsten Borgwaldt @ 2021-01-08 15:27 UTC (permalink / raw)
  To: zsh-users; +Cc: Ray Andrews

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

Am Donnerstag, 7. Januar 2021, 21:16:03 CET schrieb Ray Andrews:
> > The construct you use has side-effects you've overlooked, which mean
> > your fashion of comments will backfire in a way that you don't see yet.
> 
> I'm prepared to find out the hard way.  Guys like me suffer.

Some expressions in heredocs will be evaluated. Not a good idea for comments:

:<<EOC
$(print something > /dev/stderr)
EOC

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 15:27             ` Karsten Borgwaldt
@ 2021-01-08 15:53               ` Lawrence Velázquez
  2021-01-08 17:13                 ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Lawrence Velázquez @ 2021-01-08 15:53 UTC (permalink / raw)
  To: Karsten Borgwaldt; +Cc: zsh-users, Ray Andrews

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

> On Jan 8, 2021, at 10:27 AM, Karsten Borgwaldt <kb@spambri.de> wrote:
> 
> Some expressions in heredocs will be evaluated. Not a good idea for comments:
> 
> :<<EOC
> $(print something > /dev/stderr)
> EOC

Not if some or all of the delimiter specification is quoted (as Ray is doing, in response to a suggestion in an earlier thread):

: <<\EOC
$(print something > /dev/stderr)
EOC

vq
Sent from my iPhone

[-- Attachment #2: Type: text/html, Size: 1278 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 15:53               ` Lawrence Velázquez
@ 2021-01-08 17:13                 ` Ray Andrews
  2021-01-08 18:06                   ` Peter Stephenson
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-08 17:13 UTC (permalink / raw)
  To: zsh-users

On 2021-01-08 7:53 a.m., Lawrence Velázquez wrote:
> On Jan 8, 2021, at 10:27 AM, Karsten Borgwaldt <kb@spambri.de 
> <mailto:kb@spambri.de>> wrote:
>
>> Some expressions in heredocs will be evaluated. Not a good idea for 
>> comments:
>>
>> :<<EOC
>> $(print something > /dev/stderr)
>> EOC
>
> Not if some or all of the delimiter specification is quoted (as Ray is 
> doing, in response to a suggestion in an earlier thread):
>
> : <<\EOC
> $(print something > /dev/stderr)
> EOC
>
Good to know!  But playing with the above:

function test1 ()
{
:<<EOC
$(print something from a function with dollarsign)
print something from a function redirected > /dev/stderr
$(print something from a function both > /dev/stderr)       # This is 
the only thing that prints.
print something from a function
COMMENT from a function
echo "echo from a function"
EOC
}

... not to belabor it, but why in heaven is just that one construction 
evaluated?  zsh always has a gotcha! waiting, but someone obviously went 
to some trouble to sniff that out. Neither the '$' nor the redirection 
is sufficient alone but they evaluate together.  Why? I'd better read up 
on what here documents are really for. And it isn't comments!  But when 
I want to quickly turn off a hundred lines of code, I succumb to the 
temptation.





^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 17:13                 ` Ray Andrews
@ 2021-01-08 18:06                   ` Peter Stephenson
  2021-01-08 19:39                     ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Peter Stephenson @ 2021-01-08 18:06 UTC (permalink / raw)
  To: Ray Andrews, zsh-users

> On 08 January 2021 at 17:13 Ray Andrews <rayandrews@eastlink.ca> wrote:
> function test1 ()
> {
> :<<EOC
> $(print something from a function with dollarsign)
> print something from a function redirected > /dev/stderr
> $(print something from a function both > /dev/stderr)       # This is 
> the only thing that prints.
> print something from a function
> COMMENT from a function
> echo "echo from a function"
> EOC
> }
> 
> ... not to belabor it, but why in heaven is just that one construction 
> evaluated?

You have what is effectively a double quoted expression.  The shell
evaluates any substitutions it needs to get the arguments to the
command, so it can execute it.  It needs to do that so it can end
up with a simple set of strings, "command", "command argument 1",
and so on.  At this point it doesn't care what the command actually
is.  (In particular, it does NOT think "oh, this is Ray abusing
the ":" command, so I'd better not do my usual processing".  Nobody
has got around to adding that mode to the shell yet.)

So how it does it get "command argument 1" from the expression
you've passed to it?  There are only actually two subsitutions
in that expression to be evaluated, the two $(...) expressions;
everything else will be passed to the command as is.  That
includes anything that happens to look like a command ---
remember, it's just stuff in a double quoted string at this point.

The first $(...) is evaluated.  It has no redirection, so that
argument to the "print" is substituted into the string.  You
don't actually see that, it's just part of the command argument
now.

The second $(...) is evaluated.  This time, there's a redirection,
so the argument gets sent to stderr, so you see it.  There's
no output to stdout, so what will actually be substituted into
the argument on the command line is the empty string.

pws


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 18:06                   ` Peter Stephenson
@ 2021-01-08 19:39                     ` Ray Andrews
  2021-01-08 19:56                       ` Bart Schaefer
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-08 19:39 UTC (permalink / raw)
  To: zsh-users

On 2021-01-08 10:06 a.m., Peter Stephenson wrote:
>
>    (In particular, it does NOT think "oh, this is Ray abusing
> the ":" command, so I'd better not do my usual processing".  Nobody
> has got around to adding that mode to the shell yet.)
setopt RAY_ABUSING_ZSH

Good idea!

>
> The second $(...) is evaluated.  This time, there's a redirection,
> so the argument gets sent to stderr, so you see it.  There's
> no output to stdout, so what will actually be substituted into
> the argument on the command line is the empty string.
That's quite logical.  the $() is evaluated both times, I just don't see 
the output for one of them.  Thanks Peter.  But I still think we should 
have comment blocks.  Yeah, I know it's not shellish.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 19:39                     ` Ray Andrews
@ 2021-01-08 19:56                       ` Bart Schaefer
  2021-01-09  0:45                         ` Ray Andrews
  2021-01-09 17:28                         ` Ray Andrews
  0 siblings, 2 replies; 22+ messages in thread
From: Bart Schaefer @ 2021-01-08 19:56 UTC (permalink / raw)
  To: Ray Andrews; +Cc: Zsh Users

On Fri, Jan 8, 2021 at 11:40 AM Ray Andrews <rayandrews@eastlink.ca> wrote:
> Thanks Peter.  But I still think we should
> have comment blocks.  Yeah, I know it's not shellish.

Another approach you might consider:

(( dothis )) && {
  # all the code you want to skip over
}

That does mean that "all the code you want to skip over" has to be
syntactically valid, but it also means you can turn that code back on
with

dothis=1 zsh yourscript.zsh


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 19:56                       ` Bart Schaefer
@ 2021-01-09  0:45                         ` Ray Andrews
  2021-01-09 17:28                         ` Ray Andrews
  1 sibling, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2021-01-09  0:45 UTC (permalink / raw)
  To: zsh-users

On 2021-01-08 11:56 a.m., Bart Schaefer wrote:
>
> Another approach you might consider:
>
> (( dothis )) && {
>    # all the code you want to skip over
> }
>
> That does mean that "all the code you want to skip over" has to be
> syntactically valid, but it also means you can turn that code back on
> with
>
> dothis=1 zsh yourscript.zsh
>
Cool.  It seems less heretical.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-08 19:56                       ` Bart Schaefer
  2021-01-09  0:45                         ` Ray Andrews
@ 2021-01-09 17:28                         ` Ray Andrews
  1 sibling, 0 replies; 22+ messages in thread
From: Ray Andrews @ 2021-01-09 17:28 UTC (permalink / raw)
  To: zsh-users

On 2021-01-08 11:56 a.m., Bart Schaefer wrote:
> Another approach you might consider:
> (( dothis )) && {
>    # all the code you want to skip over
> }
>
That is so much better when it's not a comment block but a code 
variation, as when debugging something:

test1 ()
{
	(( 0 ))&&\
	{
		echo "Version #1 of some huge block of code that is buggy and I want to 'back and forth' between it and some alternate"
		# Only correct code tho, this is parsed!
	}
	(( 1 ))&&\
	{
		echo "Version #2 of some huge block of code that is buggy and I want to 'back and forth' between it and some alternate"
		# Only correct code tho, this is parsed!
	}
}

... or both can be 'off' or both can be active!  She is a dominatrix, but if you submit, pleasure awaits.  Still, the here document method is preferred for actual long comments because it colorizes differently so the eye quickly passes over in in the editor.  But slowly the Tao is revealed.  Thank you Sensei.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-07 20:16           ` Ray Andrews
  2021-01-08 15:27             ` Karsten Borgwaldt
@ 2021-01-12 13:28             ` Daniel Shahaf
  2021-01-12 14:45               ` Ray Andrews
  1 sibling, 1 reply; 22+ messages in thread
From: Daniel Shahaf @ 2021-01-12 13:28 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

Ray Andrews wrote on Thu, Jan 07, 2021 at 12:16:03 -0800:
> On 2021-01-07 7:32 a.m., Daniel Shahaf wrote:
> > Do consider treating the language as the independent variable and your
> > expectations as the dependent one, rather than the other way around.
> I'll bend it to my will as much as I can, however 90% of changes since I
> started have been me getting used to zsh rather than the other way around. 
> Still, you don't know what you don't know and however naive, my comment
> blocks do work.   If there's a crash and burn coming up I'm sure I'll burn.

I reiterate the fourth paragraph of the grandparent post.

The parenthetical describes a specific failure mode.

> > 
> > The construct you use has side-effects you've overlooked, which mean
> > your fashion of comments will backfire in a way that you don't see yet.
> I'm prepared to find out the hard way.  Guys like me suffer.

Well, you've picked your poison, then.  I'll only add that what you'll
"find out the hard way" is more than just a case in which your "idiom"
breaks.

> > By the way, I wonder if the reason we're having this thread is that it
> > hasn't occurred to you that your $EDITOR may have facilities for
> > commenting or uncommenting multiple lines.
> There's an interesting idea!  My editor doesn't but that would be quite a
> feature.

Did you actually look?


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-12 13:28             ` Daniel Shahaf
@ 2021-01-12 14:45               ` Ray Andrews
  2021-01-13 16:17                 ` Daniel Shahaf
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-12 14:45 UTC (permalink / raw)
  To: zsh-users

On 2021-01-12 5:28 a.m., Daniel Shahaf wrote:
> There's an interesting idea!  My editor doesn't but that would be quite a
>> feature.
> Did you actually look?
>
Yes sir I did.  I use a very lightweight but understandable IDE, what it 
lacks in features it makes up in being easy to use.  It's too bad 
there's no place for a guy like me to learn the ropes, I don't know 
what  I don't know.  What I'd like is to be is a fly on the wall, 
watching you adepts work for a week -- I'd learn more in that week than 
thrashing around by myself for a year.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-12 14:45               ` Ray Andrews
@ 2021-01-13 16:17                 ` Daniel Shahaf
  2021-01-13 21:57                   ` Pier Paolo Grassi
  0 siblings, 1 reply; 22+ messages in thread
From: Daniel Shahaf @ 2021-01-13 16:17 UTC (permalink / raw)
  To: Ray Andrews, zsh-users

Ray Andrews wrote on Tue, 12 Jan 2021 14:45 +00:00:
> On 2021-01-12 5:28 a.m., Daniel Shahaf wrote:
> > There's an interesting idea!  My editor doesn't but that would be quite a
> >> feature.
> > Did you actually look?
> >
> Yes sir I did.  I use a very lightweight but understandable IDE, what it 
> lacks in features it makes up in being easy to use.

(Turns out Ray's IDE does have that feature after all.)

> It's too bad there's no place for a guy like me to learn the ropes, I
> don't know what  I don't know.  What I'd like is to be is a fly on the
> wall, watching you adepts work for a week -- I'd learn more in that
> week than thrashing around by myself for a year.

You're probably right about that, insofar as discovering features is
concerned.  (To a point, anyway; 80/20 still applies.  Still, you can
look for people who post videos of themselves coding.)  However,
knowing a ton of features shouldn't be your highest priority, IMO.
It's very much like the difference between memorizing a map and
learning to navigate.

I will, for the third and last time, remind you that your fashion of
comments _will_ break, in a specific way.

Daniel


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-13 16:17                 ` Daniel Shahaf
@ 2021-01-13 21:57                   ` Pier Paolo Grassi
  2021-01-13 23:39                     ` Ray Andrews
  0 siblings, 1 reply; 22+ messages in thread
From: Pier Paolo Grassi @ 2021-01-13 21:57 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Ray Andrews, Zsh-Users List

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

> I will, for the third and last time, remind you that your fashion of
> comments _will_ break, in a specific way.

Since Ray doesn't ask, I will: what situation will break those "comments"?

Pier Paolo Grassi


Il giorno mer 13 gen 2021 alle ore 17:18 Daniel Shahaf <
d.s@daniel.shahaf.name> ha scritto:

> Ray Andrews wrote on Tue, 12 Jan 2021 14:45 +00:00:
> > On 2021-01-12 5:28 a.m., Daniel Shahaf wrote:
> > > There's an interesting idea!  My editor doesn't but that would be
> quite a
> > >> feature.
> > > Did you actually look?
> > >
> > Yes sir I did.  I use a very lightweight but understandable IDE, what it
> > lacks in features it makes up in being easy to use.
>
> (Turns out Ray's IDE does have that feature after all.)
>
> > It's too bad there's no place for a guy like me to learn the ropes, I
> > don't know what  I don't know.  What I'd like is to be is a fly on the
> > wall, watching you adepts work for a week -- I'd learn more in that
> > week than thrashing around by myself for a year.
>
> You're probably right about that, insofar as discovering features is
> concerned.  (To a point, anyway; 80/20 still applies.  Still, you can
> look for people who post videos of themselves coding.)  However,
> knowing a ton of features shouldn't be your highest priority, IMO.
> It's very much like the difference between memorizing a map and
> learning to navigate.
>
> I will, for the third and last time, remind you that your fashion of
> comments _will_ break, in a specific way.
>
> Daniel
>
>

[-- Attachment #2: Type: text/html, Size: 2238 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-13 21:57                   ` Pier Paolo Grassi
@ 2021-01-13 23:39                     ` Ray Andrews
  2021-01-13 23:54                       ` Lawrence Velázquez
  0 siblings, 1 reply; 22+ messages in thread
From: Ray Andrews @ 2021-01-13 23:39 UTC (permalink / raw)
  To: zsh-users

On 2021-01-13 1:57 p.m., Pier Paolo Grassi wrote:

>  Since Ray doesn't ask, I will: what situation will break those 
> "comments"?

I'm primed to expect it, but so far the more robust " : <<\END " form 
seems fine.
> (Turns out Ray's IDE does have that feature after all.)

You don't know what you have until you know what you're looking for.
>
>     You're probably right about that, insofar as discovering features is
>     concerned.  (To a point, anyway; 80/20 still applies.  Still, you can
>     look for people who post videos of themselves coding.)
>

Na, it's a question of soaking up the culture, it takes real time 
interaction.



^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: here document within a switch fails to parse.
  2021-01-13 23:39                     ` Ray Andrews
@ 2021-01-13 23:54                       ` Lawrence Velázquez
  0 siblings, 0 replies; 22+ messages in thread
From: Lawrence Velázquez @ 2021-01-13 23:54 UTC (permalink / raw)
  To: Ray Andrews; +Cc: zsh-users

> On Jan 13, 2021, at 6:39 PM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> 
> On 2021-01-13 1:57 p.m., Pier Paolo Grassi wrote:
> 
>>  Since Ray doesn't ask, I will: what situation will break those "comments"?
> 
> I'm primed to expect it, but so far the more robust " : <<\END " form seems fine.

This is no more or less robust than what you already had (<<'END').
Interpretation of the here-document contents is suppressed if *any*
of those characters is quoted.

vq

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2021-01-13 23:55 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-06 15:13 here document within a switch fails to parse Ray Andrews
2021-01-06 16:20 ` Daniel Shahaf
2021-01-06 17:17   ` Ray Andrews
2021-01-06 17:58     ` Lawrence Velázquez
2021-01-06 19:18     ` Bart Schaefer
2021-01-07  7:55       ` Ray Andrews
2021-01-07 15:32         ` Daniel Shahaf
2021-01-07 20:16           ` Ray Andrews
2021-01-08 15:27             ` Karsten Borgwaldt
2021-01-08 15:53               ` Lawrence Velázquez
2021-01-08 17:13                 ` Ray Andrews
2021-01-08 18:06                   ` Peter Stephenson
2021-01-08 19:39                     ` Ray Andrews
2021-01-08 19:56                       ` Bart Schaefer
2021-01-09  0:45                         ` Ray Andrews
2021-01-09 17:28                         ` Ray Andrews
2021-01-12 13:28             ` Daniel Shahaf
2021-01-12 14:45               ` Ray Andrews
2021-01-13 16:17                 ` Daniel Shahaf
2021-01-13 21:57                   ` Pier Paolo Grassi
2021-01-13 23:39                     ` Ray Andrews
2021-01-13 23:54                       ` Lawrence Velázquez

zsh-users

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-users

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-users zsh-users/ http://inbox.vuxu.org/zsh-users \
		zsh-users@zsh.org
	public-inbox-index zsh-users

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.users


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git