On 11/15/2010 12:29 PM, Justin Clift wrote:
On 16/11/2010, at 6:08 AM, Stefan Berger wrote:
<snip>
>> Ah - the plot thickens, and the light bulb goes on for me. It's not
>> just a problem with read, but also with your use of 'echo' to try and
>> replay a just-read string. 'echo' and '\' don't mix. You
have to use
>> printf for any chance of portability.
>>
>> printf %s\\n "\1"
>> printf %s\\n '\1'
> I am surprised that dash doesn't take the opportunity to already extend
"\1" or '\1' to char(1) in these cases. A mystery... :-)
>
> I'll fix it. Thanks.
We seem to have recurring problems with finding portable commands, that work across
everything.
Actually, it seems more like the problem is that the portability issues
are known and even documented in places like autoconf's manual, but
there are so many portability rules that not everyone knows them off the
top of their head (myself included), so we end up relearning the issues
every time they bite us. POSIX has helped tremendously; just ask anyone
about the hoops they had to jump through for portability 15 years ago.
But then you remember that not everyone implements POSIX correctly yet,
and it's easy to see why it's a perpetual battle.
Would use an alternative approach, such as having our own wrapper functions, be more
reliable?
(conceptually like this)
function replace_stuff()
{
if "$SHELL" = "dash"
dash specific sed here
elsif "$SHELL = bash"
bash specific sed here
else
sh fallback sed here
Here, it's not the sed that was the problem, but the use of 'echo' mixed
with backslashes. Fix the shell code to output unambiguous data by
using printf instead, and a single sed script suffices.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org