DASH Shell discussions
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox