[TUHS] Command line options and complexity

Steffen Nurpmeso steffen at sdaoden.eu
Sun Mar 15 06:25:49 AEST 2020


John P. Linderman wrote in
<CAC0cEp-dL2iPikiGvaQ_s9_6AS=mFO4RvbT423fNJ3gQiLdthQ at mail.gmail.com>:
 |Here's a command I wrote long ago using a different way to deal with \
 |options:
 |
 |  isee
 |Usage: isee format file ...
 |    Display specified inode information for files passed as arguments.
 |    Items of the form ``%X'' in format will be replaced for these X:
 |dev inode ino mode nlink uid gid rdev size atime
 |mtime ctime now filename
 |    Parenthesized printf-style format specifications can follow a %
 |    to override the default format for the various items.
 |    %filename is the name of the current file argument.
 |    %now is the time (in seconds) when the command started running.
 |    The other items are from the stat structure.
 |
 |    Example: isee "%(40s)filename: %mtime %mode" /dev/null
 |    Show file modification time and mode of /dev/null
 |
 |inode is just a synonym for ino.
 |
 |Instead of a kazillion options, the %-stat-field items identify what \
 |you want to see and the printf-style formats identify how you want \
 |them shown. Someone in the Murray Hill library added strftime 
 |formats for date fields, a fine addition, in my view. Adding readable \
 |user and group names rather than numerical ids would be worth considering. \
 |Maybe having a "rwx"-style form for mode. Sorting can be 
 |done by piping the output through sort. Don't get hung up on shortcomings \
 |of the command, just consider how a few familiar concepts and pipes \
 |can be combined to provide a large number of options.

When i switched to FreeBSD around 2001, the handbook was on the
CDs i had, and i stumbled upon a very impressive assembler
example.  It is still there[1], at least in parts(?).  Coming from
C64, then DOS/4DOS and <2 years Linux, aka kid games,
grey-industry, MS and xeyes background, i read

  [1] https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/x86-fpu.html

  Personally, I like to keep it simple. Something either is
  a number, so I process it. Or it is not a number, so I discard
  it. I do not like the computer complaining about me typing in an
  extra character when it is obvious that it is an extra
  character. Duh!

  Plus, it allows me to break up the monotony of computing and
  type in a query instead of just a number:

    What is the best pinhole diameter for the
          focal length of 150?

  There is no reason for the computer to spit out a number of complaints:

  Syntax error: What
  Syntax error: is
  Syntax error: the
  Syntax error: best

  Et cetera, et cetera, et cetera.

  Secondly, I like the # character to denote the start of
  a comment which extends to the end of the line. This does not
  take too much effort to code, and lets me treat input files for
  my software as executable scripts.

and it was like being warped from Chaplin's Modern Times to a rich
man's California style living!  And that in assembler!!

  % pinhole

  Computer,

  What size pinhole do I need for the focal length of 150?
  150	490	306	362	2930	12
  Hmmm... How about 160?
  160	506	316	362	3125	12
  Let's make it 155, please.
  155	498	311	362	3027	12
  Ah, let's try 157...
  157	501	313	362	3066	12
  156?
  156	500	312	362	3047	12
  That's it! Perfect! Thank you very much!
  ^D

Nonetheless: i never managed to create Hippie-proof programs in
real life.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)


More information about the TUHS mailing list