[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: echo "enhancement" leads to confused legacy script tools...
From: |
Linda W |
Subject: |
Re: echo "enhancement" leads to confused legacy script tools... |
Date: |
Mon, 03 Apr 2006 13:13:13 -0700 |
User-agent: |
Thunderbird 1.5 (Windows/20051201) |
Chet Ramey wrote:
The remaining consideration is whether or not there's a significant
body of scripts out there that rely on the current behavior. If there
isn't, I would strongly consider the change to require a leading `0'
in octal constants. I don't think that \x introducing hex constants
is as big a problem (it may not be a problem at all).
---
Whatever the reasoning, this is essentially what I
was suggesting -- requiring a leading zero on octal constants.
I thought it would be "cleaner" to have the added compatibility requiring
"/0" before any numeric conversions (octal or hex), having
the benefit of adding "no new, reserved 2-byte codes".
Note: by my "anal retentive" interpretation, if one
requires "/0" as a lead-in, then I would use interpretation
_only_ for valid octal or hex digits. I.e. /08 and /09
shouldn't be converted, but left "alone", similarly in a
hex constant, I wouldn't perform conversion on invalid
hex strings, i.e. "/0xg" (or "/xg") . I also would regard the presence
of a non-valid character as constant terminator, I.e:
"/018" -> "<control-A>8", just as I'd "presume" is already done
for hex constants: /xag (or /0xag) -> "<control-j>g".
As far as xpg_echo being a non-default option,
that's "unfortunate". I first learned shell in the late
80's on a korn shell that expanded such control characters by
default. I missed their presence when I switched to a BSD-compat
shell that didn't expand them.
-linda