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
next prev parent 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