HP3000-L Archives

May 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gavin Scott <[log in to unmask]>
Reply To:
Gavin Scott <[log in to unmask]>
Date:
Mon, 12 May 1997 10:27:40 -0700
Content-Type:
text/plain
Parts/Attachments:
Re: (36 lines)
Jeff writes:
> shell/iX> wc -l /DEV/SOURCE/* | tail -1
> wc: cannot execute: Arg list too long

Unix sucks.

> Any plans to expand the shell command line buffer?

This is one of those annoying indeterminate limits in all UNIX-like
operating systems.  Unix is like a room with walls covered with
jagged spikes.  As long as you stay in the middle of the room,
everything is fine.  As soon as you wander outside the bounds of
normal operation you get hurt.  The fact that most of the time the
lights in the room are out so that you can't see how far away the
walls are doesn't help.

Another example is record lengths.  There are many Unix commands
that operate on files as though they are text files containing
records separated by newline characters. Of course each program
allocates a different sized buffer for holding a "record" and
thus each has a different maximum amount of data that it can
handle between newline characters.  Thus passing
arbitrary binary data through programs that were designed to read
only files containing well-formed text data leads to some
interesting results.  In some cases you will silently lose data,
in others you will crash the program, etc.  I've even hit some
of these limits with well-formed text files that just happened to
have very long record lengths.

Modern Unices now do a better job of at least being consistent in
the behavior of their commands, but binary data still can get you
into trouble, and it's another area that makes it difficult to
develop portable applications.

G.

ATOM RSS1 RSS2