Re: bug/enhancement with echo

[Bob Proulx]

Eddie Hart wrote:
> There is a portability problem with echo.

Yes there is.  It is inherently not portable.  SysV systems do things
one way.  BSD systems do things another way.  GNU systems yet
differently.  It's a problem.

> Unlike Solaris and other System V Unices (MP-RAS, HP-UX) the GNU echo 
> command does not natively support interpretation of backslash characters.

Yes, annoying that.  But BSD based systems do things the other way.
No matter which implementation is picked half of the legacy is
broken.  Coming from HP-UX myself I have felt your pain personally.

> This behavior causes portability problems with scripts and such written on 
> other platforms. I realize that there is a -n and -e parameters exist and 
> can be utilized to provide similar functionality,

Those options are not portable and should not be used in scripts
desiring portability.

The FreeBSD man page sums this up nicely:

    Applications aiming for maximum portability are strongly encouraged
    to use printf(1) to suppress the newline character.

I agree.  I use echo all of the time, as long as I am not using escape
sequences.  As soon as I need an escape sequence I use 'printf' which
is a standard utility.  The use of 'printf' is not strictly portable
to old systems.  But printf does exist on all modern systems.

> however this requires spending valuable time to correct scripts and
> thus causes management to have an ill perceived notion that using
> Linux is a hardship they would not like to endure.

Unfortunately the behavior of 'echo' is not the only difference
between systems that you will find.  There are a number of other
portability snags that may trip people up.  Code and scripts that are
not at least somewhat maintained to adapt as the operating systems
around them evolve will have difficulties.

Fortunately the effort to do this is small and the changes required
mostly small.  I personally have been recently involved in a large
application migration from HP-UX to GNU/Linux.  A number of annoying
portability issues were found and fixed through the migration.

Let me say that vendors love managements which are locked in to the
vendor's quirks.  This allows them to charge large premiums for their
legacy systems.  Allowing yourself to require a very special
environment will cost you in the long run.  I think it is better to be
portable.  In my case management was convinced it was cheaper to move
the code forward onto modern systems and avoid being locked in.
Moving to modern systems also meant a performance increase without
rewriting the code because the new systems were faster.  The cost of
porting the code was smaller than the cost of maintaining the legacy
systems and also gained an overall performance increase.  A win all
around.  Your cost versus benefit analysis may be different from mine.

Bob