[Mingw-notify] [ mingw-Bugs-3027398 ] quote in comment puzzles shell - continuation

[SourceForge.net <no...@so...>]

Bugs item #3027398, was opened at 2010-07-09 15:40
Message generated for change (Comment added) made by hafn
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3027398&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Hafner (hafn)
Assigned to: Nobody/Anonymous (nobody)
Summary: quote in comment puzzles shell - continuation

Initial Comment:
Continuation from: quote in comment puzzles shell - ID: 3026216 (don't know how to reopen a prematurely closed bug, sorry).

Keith Marshall (keithmarshall) wrote Date: 2010-07-09 13:08

> This is NOT a bug!  You are misusing the # character in your shell command;
> it only introduces a comment when it appears as the FIRST non-whitespace
> character in the command.  If you want a comment as trailing context, you
> have to end the preceding command with a semicolon, so that # is correctly
> interpreted.

But:

- Using a semicolon does not work:

: $( echo bla; #"
)

- Making the comment the first non-whitespace character does not work:

: $(
#"
)

- More recent versions of Bash than the mentioned ones in Bug 3026216
  do it better.

- Other implementation of sh that the one emulated by bash do it
  correct. When bash is called as sh it should behave as sh, too.


----------------------------------------------------------------------

>Comment By: Thomas Hafner (hafn)
Date: 2010-07-10 10:40

Message:
Keith Marshall (keithmarshall) wrote Date: 2010-07-09 13:08

> This is NOT a bug!  You are misusing the # character in your shell
command;
> it only introduces a comment when it appears as the FIRST
non-whitespace
> character in the command.  If you want a comment as trailing context,
you
> have to end the preceding command with a semicolon, so that # is
correctly
> interpreted.

Even the buggy sh does allow comments at the given positions (trailing
or not), but it wants the quotes to be matched (!) inside the comment.

It's not OK, that a comment like this fails inside $(...):
# for Mike's account

When there's a matching apostrophe, it does not fail inside $(...):
# for Mike's account '(dummy aphostrophe)

Similiar with " rather than ':
  Fails inside $(...):
  # one " two three
  Does not fail inside $(...):
  # one " two " three

Outside $(...) comments do not fail, even if there are no matching
quotes.
Should sh behave differently inside and outside $(...)? I' sure it
should not: it's a bug.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3027398&group_id=2435