dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Eric Blake <eblake@redhat.com>, Bosco <jbosco.gg@gmail.com>,
Subject: Re: echo "\\1"?
Date: Thu, 27 Jul 2017 19:26:36 +0200	[thread overview]
Message-ID: <6d70fb7f-ab21-8675-350a-218f2db3ba6e@gigawatt.nl> (raw)
In-Reply-To: <68dddf01-263e-77bd-ffc7-8e7df386ee8f@redhat.com>

On 27/07/2017 16:24, Eric Blake wrote:
> On 07/27/2017 08:13 AM, Bosco wrote:
>> On 27 July 2017 at 12:54, Eric Blake <eblake@redhat.com> wrote:
>>> Which man pages?  Echo is one of those programs that varies widely, and
>>> you are MUCH better off using printf(1) instead of echo(1) if you are
>>> trying to get newline suppression, trying to print something that might
>>> begin with -, or trying to print something that might contain \.
>> Sorry, maybe I did't explain it correctly, I mean the man pages of the
>> dash source:
>> https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/dash.1#n1202
>> And because of this, I got an error compiling zziplib, you may see
>> https://github.com/gdraheim/zziplib/blob/v0.13.67/configure#L17542
> Eww - storing generated files in git - that forces everyone that checks
> out your project to use the EXACT same version of autotools to avoid
> changing the generated files unintentionally.
> Looking at those lines:
>>    if test -f $ac_prefix_conf_INP ; then
>>      echo "s/^#undef  *\\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]\\)/#undef $ac_prefix_conf_UPP""_\\1/" > conftest.prefix
> ac_prefix_conf_INP is not defined anywhere in autoconf 2.69 sources (and
> you really shouldn't use the ac_ prefix if you are writing code that is
> not part of autoconf proper).  I couldn't find mention of it at
> https://github.com/gdraheim/zziplib/blob/v0.13.67/configure.ac, but it
> may be in one of your other included files.  Can you pinpoint which part
> of your configure.ac results in that part of the generated configure
> file?  In all likelihood, you are using a buggy macro that is using
> autoconf primitives incorrectly, and thus resulting in non-portable
> code.  But without seeing the true source, I can't help you debug your
> problem.

This is coming from zziplib's outdated copy of ax_prefix_config_h.m4, 
for which I submitted a patch to make it work in dash, and which was 
accepted, back in 2010 (!): <https://savannah.gnu.org/patch/?7317>

zziplib should update to a current version of this file.

>>> Arguably, since it is not required by POSIX, we don't have to do it. But
>>> I also can't argue that POSIX forbids us to support \1 as an extension
>>> (it says nothing about whether implementations can have additional
>>> escape sequences).  So I'll argue that it is intentional as a dash
>>> extension.  But if you can make dash smaller by getting rid of the
>>> extension, that might be an acceptable patch.
>> In that case, I think, the man page of dash should be modified with
>> that extension.
> Indeed, or the fact that it is NOT documented means that it is an
> unintentional bug for providing the extension.

The man page of dash states:

   All other backslash sequences elicit undefined behaviour.

Implementation-wise, POSIX gives the same requirements for escape 
sequences for echo as for printf %b, therefore it makes sense to share 
the code between the two. Neither echo nor printf %b requires \1 to be 
treated as an escape sequence, but both allow it.

bash treats \1 as an escape sequence with printf %b. For compatibility 
with bash, it sort of makes sense to implement this in dash as well. Yet 
for some reason, bash *doesn't* treat \1 as an escape sequence with 
echo, not even with echo -e.

Keeping dash small, continuing to share the code between the two cases, 
can only mean behaving differently from bash in at least one of them.

Harald van Dijk

      parent reply	other threads:[~2017-07-27 17:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-27 12:23 Bosco
2017-07-27 12:54 ` Eric Blake
2017-07-27 13:13   ` Bosco
2017-07-27 14:24     ` Eric Blake
2017-07-27 14:44       ` Bosco
2017-07-27 14:51         ` Eric Blake
2017-07-27 15:10           ` Bosco
2017-07-27 15:19             ` Eric Blake
2017-07-27 15:32             ` Bosco
2017-07-27 17:26       ` Harald van Dijk [this message]

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:

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

  git send-email \
    --in-reply-to=6d70fb7f-ab21-8675-350a-218f2db3ba6e@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=dash@vger.kernel.org \
    --cc=eblake@redhat.com \
    --cc=jbosco.gg@gmail.com \
    --subject='Re: echo "\\1"?' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).