dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shware Systems <shwaresyst-YDxpq3io04c@public.gmane.org>
To: oleg-BA2faJl1U0pBDLzU/O5InQ@public.gmane.org,
	eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
	dash-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org,
	Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org
Subject: Re: heredoc and subshell
Date: Wed, 24 Feb 2016 07:27:17 -0500	[thread overview]
Message-ID: <153133f6f0b-66ff-2f8@webprd-a36.mail.aol.com> (raw)
In-Reply-To: <56cd8cd1.LdVYbpfe+0tQMm8I%Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org>

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

Near as I can tell, from 2.3, io_here has precedence over string concatenation of normal tokenization so the output of bash should be:
A:echo line 1
Syntax error: Missing right paren
Syntax error: Missing closing double quote

as the list production terminates at the first newline, and a new one doesn't start until after the second line with XXX to satisfy the second io_here. It can be argued provisions for trying to find the end of an open string should continue after the io_here body, but Item 7 of 2.3 has the newline terminating it.

The first newline is the one left after line joining has been done. Before tokenization starts the input file position should be pointing to the character after it so the first io_here can immediately start reading the body from there until the first XXX line, and that advances it so the second might be processed, and the line after starts a new list, not continues as if no io_here was present. The syntax error detection happens before the second block gets consumed, but the presence of the operator while scanning for the right paren reserves it.



On Wednesday, February 24, 2016 Joerg Schilling <Joerg.Schilling-8LS2qeF34IoQrrorzV6ljw@public.gmane.orgnhofer.de> wrote:
Eric Blake <eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:

> > --- code
> > prefix() { sed -e "s/^/$1:/"; }
> > DASH_CODE() { :; }
> > 
> > prefix A <<XXX && echo "$(prefix B <<XXX
> > echo line 1
> > XXX
> > echo line 2)" && prefix DASH_CODE <<DASH_CODE
> > echo line 3
> > XXX
> > echo line 4)"
> > echo line 5
> > DASH_CODE
> > 
> > --- bash 4.3.42 output:
> > A:echo line 3
> > B:echo line 1
> > line 2
> > DASH_CODE:echo line 4)"
> > DASH_CODE:echo line 5
>
> So, it looks like bash is interpreting this as "first newline that is
> not in the middle of another shell word), and parses the entire $(...)

I would like to get an explanation on what I should understand by:

	"first newline that is not in the middle of another shell word)


BTW: If I replace $(..) by `..` and feed the code to the original SVr4 Bourne 
Shell, I get the same output as you got from bash. I would guess that the bash 
output you added above is correct.

Note that the command substitution is part of a " quoted string and even 
without that, it would need to be parsed first.

The POSIX version from ksh88 (seen on Solaris) behaves the same with $(..) and 
the `..` variant and the same as bash.

The fact that ksh93 behaves different with $(..) and the `..` variant makes it 
obvious that ksh93 has a bug.

Jörg

-- 
EMail:joerg-lSlhzV3CM+2sTnJN9+BGXg@public.gmane.org (home) Jörg Schilling D-13353 Berlin
joerg.schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/'


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

  parent reply	other threads:[~2016-02-24 12:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 22:07 heredoc and subshell Oleg Bulatov
2016-02-23 22:49 ` Eric Blake
2016-02-23 23:16   ` Eric Blake
     [not found]   ` <56CCE1E3.1060805-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-24 10:58     ` Joerg Schilling
     [not found]       ` <56cd8cd1.LdVYbpfe+0tQMm8I%Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org>
2016-02-24 12:27         ` Shware Systems [this message]
2016-02-24 12:32           ` Joerg Schilling
2016-02-24 20:27       ` Oleg Bulatov
2016-02-23 23:18 ` Jilles Tjoelker
2016-02-24  8:46   ` Thorsten Glaser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=153133f6f0b-66ff-2f8@webprd-a36.mail.aol.com \
    --to=shwaresyst-ydxpq3io04c@public.gmane.org \
    --cc=Joerg.Schilling-8LS2qeF34IpklNlQbfROjRvVK+yQ3ZXh@public.gmane.org \
    --cc=austin-group-l-7882/jkIBncuagvECLh61g@public.gmane.org \
    --cc=dash-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=eblake-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=oleg-BA2faJl1U0pBDLzU/O5InQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).