Hacker News Reader

Comment by Annatar | Hacker News Reader

ed is perfect in shell scripts:

  % cat <<- _EOF_ | ed -s filename
      ed commands...
  _EOF_

works on all UNIX-like operating systems and it means that temporary files are no longer necessary. (GNU sed -i is an architectural violation of the idea of a stream editor, and it isn't available everywhere.)

View on HN

Useless use of cat though. You could achieve the same thing by:

  % ed -s filename <<- EOF
      ed commands...
  EOF

I routinely automate text-mangling tasks with short ex (most of them would probably work in ed, too) scripts. I find it simpler than using sed, most of the time. If you're comfortable using ex commands in vim, then it's almost a seamless transition

FreeBSD found out it is not perfect since they had to patch patch because it called ed. People figured out how to run arbitrary scripts in a privileged manner.

patch(1) outputs ed(1) commands. It always worked that way, and it demonstrates the power of the "do one thing and do it well": patch just does the analysis and generates the appropriate editting commands, but the editting is passed on to a program specialized for just that: ed(1). It as also a good showcase for UNIX modularity principle.

It's a good demonstration up until it turns into an attack vector. Then it violates the "do one thing well" part.

It is unclear what this tries to achieve. Could you please explain why this removes the need for temporary files?

If you want to perform an in-place edit, and you want to do it in a portable manner (not using GNU sed -i), you'd have to use sed with at least one temporary file:

  % sed -e 's/something/other/' somefile > /tmp/temp.$$ && mv /tmp/temp.$$ somefile

now, using ed (or AWK) and the heredoc with ed commands above, you can mmap(2) the entire file into memory, perform desired editting, and write it all out in one go. No more temporary files!

Sed, when operating on a file, creates a temporary file alongside the target file.

sed -e s/foo/bar/ | sponge filename

https://joeyh.name/code/moreutils/

You can also use the -i flag of sed to edit a file in-place. It leaves a backup file with the original in case you messed up.

I explicitly wrote:

GNU sed -i is an architectural violation of the idea of a stream editor, and it isn't available everywhere.

precisely to preclude anyone from suggesting using GNU sed -i.

sponge is found on GNU/Linux, but is not a UNIX standard; when writing shell programs one must never assume GNU/Linux, because, as my ed(1) example shows, it is completely unnecessary and makes the code unportable for no reason whatsoever.

Also by relying on external tools, you have now forced your users down the dependency hell path.

Assume the environment you're writing scripts for. Most scripts need only be run on one machine, and thus one platform. Most that don't still run only on one platform. If you need a portable shell script, by all means write one, but that's rarely the case.

Assume you know how to write shell programs which work everywhere without modification; why would you make your program unportable on purpose?

In some cases, it can significantly shorten and clarify the code. That's a Good Thing. Nobody wants to debug shell scripts.

The clean / portable way is in my experience always simpler, or rather, more rudimentary than using unnecessary GNU/Linux-only commands and constructs, simply because the clean / portable methodology uses the lowest common denominator.

If you know of, or have such a case, I would be really interested to see it, out of purely professional interest.

Nobody wants to debug shell scripts.

I want to debug shell scripts, because of all the debugging I've done over the years, shell script debugging is by far the quickest / easiest:

  DEBUG="${DEBUG:-false}"
  $DEBUG && set -x

and one can see the machine state immediately. Best debugging experience by far.

Reply on news.ycombinator.com