Hacker News Reader

Comment by mrb | Hacker News Reader

Then take the 5-10 minutes to scan the man pages. Write a simple shell script wrapper exposing a syntax as simple as "replace". And be done with it in 15 minutes top. It seems to me that writing all this js code would take a lot longer than 15 min.

View on HN

The issue is that it's 5-10 minutes to scan each man page every single time I want to use sed, find, xargs, etc.

I quickly reach a point where I just think "Fuck it, I'm writing a Python script for this."

A simple tool that only takes a couple of minutes to learn, then a five second look at the man page to refresh the syntax is very valuable, particularly if it focuses on doing the one job that people want to do most often.

You completely skipped over reading his post, and thus your response makes no sense. Read the docs once, and write your weird syntax version as a shell script. Then you don't need to look it up ever again, because you are using the weird syntax you invented for yourself. It is just much simpler and easier to do it the reasonable way than to write it in javascript.

I didn't misread it at all. I just completely disagree that it's 10 minutes to work out how they all work. And that's every time you want to use them, because few people use them often enough to learn the tools properly.

You said:

> The issue is that it's 5-10 minutes to scan each man page every single time I want to use sed, find, xargs, etc."

Which means you could put in a one time investment, write a wrapper shell script, and be done.

And if you insist on disagreeing still, then that's fine, but the this whole point was brought about in response to:

> I've used CLI tools for years, and it would probably take me 5-10 minutes of scanning the man pages to reproduce all but the simplest of those snippets.

You keep saying that you have to research how they work every time. But we tell you: no, you only have to write the wrapper shell script once. It is a one-time effort. Just like harthur put a one-time effort in writing "replace". You wouldn't have to remember find/sed every time, just like harthur doesn't have to re-write "replace" every time.

You are the one who claimed 10 minutes. If you didn't misread, then you are deliberately ignoring what people are saying just to be obstinate.

I think the point everyone is trying to make here is. Should every person spend 5-10 minutes doing this?

If the problem occurs too frequently, it makes more sense to make the solution re usable. Which is exactly what 'replace' is doing here.

> I think the point everyone is trying to make here is. Should every person spend 5-10 minutes doing this?

Exactly. People tell me "Nobody needs ack, you just write wrappers around find+grep" and I say "You could, but I published it and now people don't have to."

This reminds me of the first of Larry Wall's three virtues:

"[Laziness] makes you write labor-saving programs that other people will find useful, and document what you wrote so you don't have to answer so many questions about it. Hence, the first great virtue of a programmer."

I use ack, but that's because it searches for the right file types, ignores source control directories automatically, and has pretty colors, not because it's find+grep.

Other than "pretty colors", your statement contradicts itself. Doing the things you mentioned is being find+grep. That's the entire point of ack, to be find+grep.

I didn't say that find couldn't ignore source control directories or find only specific file types. However, ack does that far better as it has a better semantic awareness of both concepts.

I don't have to worry about updating my find command lines to account for new types of source code or source control folders in unfamiliar programs, I need only ensure that ack is kept up-to-date.

I'm not sure what you are trying to say. Your post contradicted itself. You literally said "I don't use ack because it is find+grep, I use it because it is find+grep". I am simply pointing this out.

Except by that logic, you could say that any user of a high-level language was really claiming (in the end) to be using assembly.

C++ once compiled to C, but even then people wouldn't claim they were using C, they'd claim they were using C++. "I don't use C++ because it's C with 'classes', I use C++ because it sets up my vtables and overloaded functions"

That analogy makes absolutely no sense. You are claiming an intended use. And then contradicting yourself by saying you don't use it for that intended use. The analogy would be "I don't use C++ to write programs, I use C++ to write words that have a particular syntax that a C++ compiler can understand and translate into executable machine code". And that statement is just as contradictory as the one you made.

Then write it once and share the wrapper script on github. No?

C'mon we are long past the days where tools had to written in $somelanguage. These are days where even things like compilers and databases are not being written in C.

If its of any help I think its time for the Unix community as a whole to sit down and self reflect. If people are beginning to think something like 'sed' as too level to use, then better job needs to be done to make them more accessible and usable. There are enough examples on this thread where people are saying that they look at sed as an API on top which a program needs to be built up on. And not a complete program in itself. Also shell is not a full fledged programming language.

I respectfully disagree with you here. The beauty and the wonder of these small command line tools (for me, at least) is that they are a) small and b) fast and c) ubiquitious. I do a lot of data manipulation, and while I'll do anything complex in a real programming language (with a REPL) sed, awk, grep and find are really really handy for quick data finding and manipulation.

Any new API on top of them would only be present on a fraction of machines, and thus would reduce the major advantage of them in that they are available everywhere.

Wow, you actually stated something that was wrong enough to force me to comment. The beauty of these tools are that they are small, fast, ubiquitous, AND easy to replace with other tools if they fit your problem better. Unix was built exactly for swapping in these small one-off programs and to deny that is to deny the beauty of it's design and to basically ignore the fact that the system is built to string arbitrary programs together to solve complex problems in simple ways.

One advantage of her Javascript replace is that she can drop it on any machine with a Javascript runtime and it will work, unlike sed.

And the real truth is, she wrote something that solves a problem she has, which is the measure of her success, not someones arbitrary comments.

Why do you have such a strong objection to someone spending their own free time to simplify and / or mimic [insert unix tool functionality here].

It clearly serves a purpose and it's apparently useful. Most importantly, it exists, so there's no need to argue over how you think it should have been implemented.

I'm sure if you were to release your own [script / wrapper], someone would find use for it, in the same manner that some have apparently used 'replace'. I honestly fail to see the big deal here.

I know it someone's right to do this, of course. I object because I come from an environment (software industry) where I have spent hundreds of hours undoing people's poor jobs where they wasted time and money reimplementing (incorrectly) library functions, system commands, etc. Because of this personal experience, I reacted the same way many reacted when seeing her script. So, I decided to explain to her and attempt to convince her that she should have spent her time and skills on something else (especially because she seems a rather good programmer!) Does it make sense?

Fair. I can see where you're coming from.

I object because I come from an environment [...] where I have spent hundreds of hours undoing people's poor jobs where they wasted time and money reimplementing [...] system commands

What you fail to take into account is that there's definitely a niche for Node.js-based development tools such as this script: The GNU userland is not ubiquitous.

Node.js did not come with a system command to search and replace across files - now it does.

It's a one off tool, unlikely to be used in any project you are writing software for. She provided the source code freely, and the code isn't bad at all.

I fail to see why you will ever need to rewrite this?

You have better things to do than tell people to invent time machines to go back and not do things that are already done.

The point everyone seems to be making is that there is no reason to do this in javascript if it's for command line use. Implementing it in js like this is just silly.

JavaScript has a widely used, native regular expression engine. That's enough technical defense on its own for that particular design decision, besides the usual, "Reimplementing a unix command-line tool in your favorite language is always a useful exercise."

> It seems to me that writing all this js code would take a lot longer than 15 min.

Probably, but I can't really speak to that.

Either way, we were originally talking about the syntax & implementation. It doesn't make a lot of sense to object to a hobby script on the basis of development time.

Well, the whole point is that writing sed-replacement in the language of your choice really is simpler/quicker than learning to write decent "simple shell script wrappers exposing a syntax".

Such wrappers aren't lingua franca anymore - nowadays they are as arcane and as COBOL, since [for most X] it's easier to write a perl|ruby|JS script to do X than a shell script to do X.

Starting from scratch (say, from a Win background) it might be easier to learn a language like Haskell or Scala than to learn the shellscript language with the whole pack of sed/awk/grep/etc flags and tricks.

Add another 30 minutes or so for learning how to write a shell script. I mean how to pass variables into a shell script and stuff like that. Actually no idea if 30 minutes are sufficient for learning how to write shell scripts (it can get pretty confusing with environment variables that are suddenly not available and what not).

Who cares how long it took the author? The API is what matters. And I personally think her API beats the snot out of obscure sed, awk,and grep compositions.

Reply on news.ycombinator.com