Re: here strings

Re: here strings

[Alan Watson]

Sorry, John, but I'm not convinced by your example, although there may
be something I have missed.

The precise behaviour of your example can be reproduced by:

   for ( f in * ) mv $f `{ echo -n $f | tr A-Z a-z }

assuming echo is built-in (or an external, non-SYSV echo).  I strongly
suspect that your here-string solution is not very much faster than
this one, if echo is a built-in command.  So, I would tentatively class
your idiom as a speed hack on a system without a built-in echo (like
some of the means of getting at the file system through the globber and
builtin cd).

As I see it, the justification for here-strings is that echo is not a
necessarily available as a built-in, and so one cannot reliably convert
a here-document to a a series of echoes.

Re: here strings

[malte]

So let me say I'm very sorry I didn't get the hint from your mail header:
"John (Most modern computers would break if you stood on them) Mackin".

But to all the non expert text tool users out there: The point is not all
tools deal correctly with non-newline terminated here strings. I spent
quite some time discovering this when I wrote a shell script that ran fine
with path = ( /vol/gnu/bin ... ) but didn't with path = ( /bin ... )
on a Sparc running SunOS 4 and another running SunOS 5.

	; /vol/gnu/bin/sed 's/a/e/g' <<< aaaaaa
	eeeeee
	; /bin/sed 's/a/e/g' <<< aaaaaa
	;

Because of this, I refuse to use here strings since their semantic is confusing
me and - if not avoidable - is replacable by "echo -n", unless someone can
show me a counter example.

I do not want to throw here strings out because that'll probably break a lot
of existing scripts. I'd just wanted to state their superfluousness.

Malte

Re: here strings

[malte]

	a directory full of files that had come from, ah, another operating
	system, and the names were all upper-case:

		for (f in *) mv $f `{tr A-Z a-z <<<$f}

	OK,
	John.

Your lucky this worked because most (especially on older unixes) text
utilities require their input to end in a '\n'. Then you'd have to

		for (f in *) mv $f `{echo $f | tr A-Z a-z}

Malte

Re: here strings

[John Mackin]

[Me:]
    		for (f in *) mv $f `{tr A-Z a-z <<<$f}

[Malte:]
    Your [sic] lucky this worked because most (especially on older unixes) text
    utilities require their input to end in a '\n'.

(let ((high-horse 'on))

Normally, I'd keep this private, but since Malte chose to toss a dart at my
reputation on the list, I am replying to the same place.

I have been a Unix professional for over ten years, and I am certainly
N O T  `lucky this worked.'  I knew damn well that it would work.  I am
keenly aware of this historical development of Unix commands, and I know,
and have known since the day I first used it (let's see, must have been
on Sixth Edition in 1979) that "tr" is a plain _character-oriented_
command.  It is not a text tool, it is a character tool.  I know
you know that.  What I am telling you is that I always knew it.
There was not the slightest bit of `luck' involved.  If your tr
needs a terminal newline, your tr is busted, end of discussion.

)

OK,
John.

here strings

[John Mackin]

Hands off here strings, you unprincipled boors!  Real Example time
(flog that dead horse, I know, but this was too good not to mail,
and the old hands know how I feel about Real Examples): I had
a directory full of files that had come from, ah, another operating
system, and the names were all upper-case:

	for (f in *) mv $f `{tr A-Z a-z <<<$f}

(Adjust your brain, and your $home/bin, as needed if your tr is infected
with the SysVile square-bracket virus... they're _not_ character classes!)

OK,
John.