All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Paul Gilmartin <PaulGBoulder@aim.com>
Cc: dash <dash@vger.kernel.org>
Subject: Re: [PATCH] \e in "echo" and "printf" builtins
Date: Sun, 29 Jun 2014 11:28:50 +0200	[thread overview]
Message-ID: <53AFDC52.3060902@gigawatt.nl> (raw)
In-Reply-To: <3DBAFEEE-9555-483E-8260-7D5E9B47F9AD@aim.com>

On 28/06/14 19:33, Paul Gilmartin wrote:
> On 2014-06-28, at 10:52, Harald van Dijk wrote:
>> No comment on whether dash itself should accept \e, but you already
>> found a compiler that doesn't support it at all, and many of the ones
>> that do support it also (optionally) issue a warning for it. Should the
>> C code perhaps be using \033 instead of \e?
>>
> And here I put on my EBCDIC hat (crown of thorns) and say, "Be careful
> using numeric code points; they're not portable."

The way GCC does this is to hard-code the values for ASCII, and to
hard-code the values for EBCDIC, both hidden behind preprocessor macros.
Taking that approach in dash would look something like

#if defined(ASCII)
#define ESCAPE '\033'
#elif defined(EBCDIC)
#define ESCAPE '\047'
#else
#error Unknown character set
#endif

and then use ESCAPE.

ASCII and EBCDIC would be detected (or specified) by the configure script.

But dash does have an assumption of ASCII already, which is why I didn't
think it would hurt to add one more. At the very least, it uses
hard-coded \033s in src/hetio.c, so that part of the code already cannot
be used on EBCDIC systems.

Cheers,
Harald van Dijk

  reply	other threads:[~2014-06-29  9:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-28  4:56 [PATCH] \e in "echo" and "printf" builtins Adam Borowski
2014-06-28 16:52 ` Harald van Dijk
2014-06-28 17:27   ` Adam Borowski
2014-07-23  9:11     ` Adam Borowski
2014-07-23 10:26       ` Jérémie Courrèges-Anglas
2014-06-28 17:33   ` Paul Gilmartin
2014-06-29  9:28     ` Harald van Dijk [this message]
2014-06-30 13:08     ` Eric Blake

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=53AFDC52.3060902@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=PaulGBoulder@aim.com \
    --cc=dash@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.