[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sed and limited record length
From: |
Ralf Wildenhues |
Subject: |
Re: sed and limited record length |
Date: |
Mon, 22 May 2006 13:22:26 +0200 |
User-agent: |
Mutt/1.5.11 |
Hi Gary,
* Gary V. Vaughan wrote on Mon, May 22, 2006 at 01:07:19PM CEST:
> Ralf Wildenhues wrote:
> >* Gary V. Vaughan wrote on Mon, May 22, 2006 at 11:45:01AM CEST:
> >>
> >>foo=`echo X"$bar " | $SP2NL | $Xsed -e baz | $NL2SP`
> >that will still be the case, after
> > | $NL2SP
> >
> >it will be space-space. Then, the shell is to rip off the final
> >newline, if any.
>
> That part was deliberate on my part; I thought you were worried that
> for some implementations of $Xsed input that didn't end with a NL
> would be problematic...
Yes. But in above sequence, that can't be the case. I think we've
clarified this now.
> > My point is that some shells may be confused iff
> >there is no final newline. That's what the ($NL2SP; echo) would be for.
> >
> >I simply don't know whether that is necessary for some broken shells.
>
> ...but you are worried that there are shells that don't like backtick
> substitutions that don't end with a newline? I would be amazed if
> such a shell could even come close to being able to run a typical
> configure script.
I would be, too. But given how some old shells implement quoting
internally (8bit stuff and the like), I wouldn't be too surprised
if they were "interesting" wrt. backtick expansion, too.
In fact, there is a "modern" system which has had issues in this
regard: MinGW (and I assume Cygwin) have at times failed to strip
the \r from a \r\n ending in such an expansion. The libtool.m4
code witnesses this at several points, somewhat inconsistently.
> Or do you mean there are shells where the later
> ``eval $bar'' will fail without a trailing newline?
I hope not.
Cheers,
Ralf