6 ms·

Honestly, I think you ended up really making the case for replace. The nix CLI examples are convoluted at best. I've used CLI tools for years, and it would pro

• mrb 14y ago
  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.
  • kamaal 14y ago
    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.
    • petdance 14y ago
      > 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."
      • fruchtose 14y ago
        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."
      • mpyne 14y ago
        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.
        • papsosouid 14y ago
          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.
          • mpyne 14y ago
            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.
            • papsosouid 14y ago
              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.
              • mpyne 14y ago
                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"
                • papsosouid 14y ago
                  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.
    • mrb 14y ago
      Then write it once and share the wrapper script on github. No?
      • kamaal 14y ago
        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.
        • disgruntledphd2 14y ago
          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.
          • trilobyte 14y ago
            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.
    • kaosjester 14y ago
      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.
      • sirclueless 14y ago
        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."
  • doktrin 14y ago
    > 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.
  • Tichy 14y ago
    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).
  • scott_w 14y ago
    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.
    • deleted 14y ago
      [deleted]
    • papsosouid 14y ago
      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.
      • scott_w 14y ago
        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.
        • burntsushi 14y ago
          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.
        • mrb 14y ago
          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.
  • PeterisP 14y ago
    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.
  • DigitalJack 14y ago
    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.
• vidarh 14y ago
  I agree. I've used Linux for 18 years, and I'm comfortable with all the find and xargs use. But sed is too obnoxious. Beyond the extremely trivial, I'd do stuff in Ruby instead rather than bother with scouring the sed documentation to figure out what I need. I might have an issue with doing a replacement in JS for node, though. But for those who are already using node, why not.