24 ms·

Heather, I agree that people are unnecessarily rude to you. Don't sob. Your code shows you are already a more capable programmer than most of the ones I intervi

• enjo 14y ago
  I'd ague that her version is at the very least syntactically much easier to use.
  • SomeCallMeTim 14y ago
    Hear hear! I've had a sed book on my shelf for years and I've used it more than once, but 99% of the time I end up giving up on sed and using a GUI-based tool instead of trying to concoct the cryptic lines given above as examples. I absolutely would rather use the clean interface of replace, written in JavaScript or anything else, than to memorize that steaming pile of cruft.
    • Domenic_S 14y ago
      Two reasons why it's better to memorize the cruft: 1. You can pipe find/sed/grep/cut/awk/whatever to other utils. Today you might be replacing, tomorrow you might be analyzing text logs, and the more core utils you learn the more things you can do with them. 2. When you're ssh'd into another box that doesn't have that spiffy replace utility, now you don't know how to do an inline replace.
      • cjg 14y ago
        Your argument that it wouldn't be available on other boxes can be applied against any new command, no matter how fantastic, so it doesn't seem very constructive to me.
        • webreac 14y ago
          I think it is a good argument to learn basis before reinventing the wheel. When using unix, there are already far too many commands to learn. Not having to learn useless commands is a bonus.
          • chris_wot 14y ago
            And yet, it's not useless to so many.
        • yb66 14y ago
          I agree wholeheartedly. As an example, many languages are Turing complete and yet we still keep creating new languages when just one (theoretically) would do. It's because syntax is separate from meaning, syntax matters (compare addition in Roman numerals to our current number system, same meaning, improved syntax). Also, problem domains differ, but here it's a problem of syntax, and the argument against "reinventing the wheel" is moot if you're moving from a wooden wheel to one with spokes and a tyre.
• RaphiePS 14y ago
  Am I the only one who finds replace's syntax much nicer? I haven't spent much time learning unix utilities, so that might explain it. But I can't help but shudder at find . -type f ! -name '.min.js' ! -name '.py' -print0 | xargs -0 sed -ri 's,var,let,g'
  • mrb 14y ago
    She was able to simplify her command line interface in order to support only the features she needed, so of course her syntax is nicer. Whereas sed/find/xargs can do a lot more things, so of course they come with a more evolved syntax. It is the usual tradeoff between simplicity and features.
    • mindcrime 14y ago
      Right... she had different requirements, so she wrote a different tool. Which is why I find your near-rant above somewhat disturbing. It seems predicated on a (seemingly) very arrogant belief on your part, that you know more about what harthur needs, then she does. Personally, I am very sceptical on that point. There is only one case that justifies reimplementing things Or, um, how about the one that goes "I felt like it"? That's sufficient justification in my book.
    • blader 14y ago
      Yeah, who needs TextMate when you have vim, right? Or Ruby when you've got Perl?
      • jrogers65 14y ago
        I beg to differ on your first argument. Learning Vim was one of the best decisions I've ever made in terms of how I write code. Other editors feel like toys in comparison. I'm siding with mrb on this one. Learning flexible tools gives you immense power in comparison to low-learning-curve ones. The time invested is considerably smaller than the time spent figuring out how to solve edge cases with simple tools. This is something which appears to be impossible to communicate to people with words. Learn some of these tools and you will see for yourself. By 'learn' I do not mean, for example, becoming familiar with hjkl for navigation in Vim. I mean mastering the tools to the point that using them requires no effort - where just as you experience the impulse "I want a glass of water" and without any effort go to fetch one, you experience the impulse "I want to create a new class in file X, navigate to file Y then modify method Z", your fingers start moving and suddenly you're done. I get frustrated watching my IDE using co-workers write code - it takes them a very long time to do very simple things. Their tools are narrow and do not facilitate expression - they constrain it. Pre-emptive strike on the argument that code completion is better - Eclim (Eclipse with a Vim frontend) solves this problem very well. Nonetheless, I have it installed and configured but can barely find a use for it.
• tptacek 14y ago
  I've been coding since 1993 and I have never made room in my brain for stuff like -print0. Moreover, there are times when you'll want to do this stuff from within another program. What are you going to do, shell out to a find(1) pipeline? Then people like me will be giving you shit. There's nothing wrong with rewriting sed in Javascript.
  • _ZeD_ 14y ago
    Please, tell me you're jocking: on your platform you cannot afford a pipe but you can launch node.js? by the way: "-print0 | xars -0" is really idiomatic, you know? Lucky you didn't have a single filename with spaces to handle...
    • tptacek 14y ago
      I don't know what this even means. I'd already be running v8 runtimes. They're unavoidable. But there's no need to fork and exec (many times over) just to sweep a filesystem tree for files matching patterns. It's the shell, by the way, that cares about "spaces in filenames". Not dicking around with shell metacharacters is just one of the many wins you get by not shelling out to accomplish basic programming tasks.
      • aidenn0 14y ago
        I get what you're saying for the "already in a REPL" thing, but as far as fork/exec overhead, xargs does a single fork/exec for every thousand or so files you search; the overhead is tiny compared to everything else.
        • dvdkhlng 14y ago
          Not even that, but xargs can also be made to run N processes in parallel ('xargs -P N'), making a find|xargs sed pipe perform much better than anything you could easily invent on your own. Note that 'xargs -P' behaves very similar to 'make -j' and is often useful as a simple work-unit scheduler.
    • 14y ago
• HaloZero 14y ago
  Replace looks a LOT cleaner to read and write though and more intuitive though for smaller/simpler things such as these examples.
  • EdiX 14y ago
    Learning how find, grep and a bit of sed works is a better investment of time, they have a broader use than this replace utility.
• petdance 14y ago
  > There is only one case that justifies reimplementing things Who are you to decide how she may spend her time? Why in the world do you think that she has to justify to you what projects she creates?
• roguecoder 14y ago
  I'd argue that wrapping crappy syntax is decent syntax is 90% of what tools do.
  • zobzu 14y ago
    I often write wrapper scripts to make complex syntax simple. Just for me. Don't get me wrong. i actually _know_ the f* syntax because I'm and old crazy fart like that by now. But when it comes to use it, it takes a while to type. Sometimes I make typos. Sometimes i forget one specific option or character and I gotta look in man again. The simplified syntax wrappers make it f' easy. The other day I made a csv column grepper. It just calls awk and assign numbers to column names, so i can just grep by column names no matter their order. So yeah, a huge line of awk can do it. An even less understandable line of grep can actually do that too. Some other tools as well. Mine is just ./supertool colname colname colname ... | awk "$2 != blah" |column -t (For the record, there were similar wrappers in python and perl, each of which were 5 to 35x slower (200 to 1000 lines script) than my 20 lines bash script, which is another complain I have. Reimplementing that stuff in high level languages is generally a bad idea, specially when you don't understand what happens underneath.
• jongala 14y ago
  To my (naive) eyes, your examples act as a compelling advertisement for her library. The sed/xargs/etc. examples look increasingly like impossible-to-memorize line noise to me, while the --include, --exclude etc. options in `replace` are comprehensible and seem to follow standard command line argument practices. Again, this is from a very entry-level unix tools perspective, but there it is. It also seems to me that reimplementing things with the stated goal to make them easier to use has to be one of the best justifications around, no? I hope I sound as respectful here as you did in your comment -- I certainly appreciated seeing a clear response to her library, so thanks for that.
  • mrb 14y ago
    Impossible to memorize? I wrote all these examples from memory. I tested them in a shell and had a single error (sed -ir needed to be changed to sed -ri because -i takes a glued "suffix" argument). I really don't think it is that hard to memorize the basic find/xargs options. You only have to memorize them once in your lifetime. They are a basic cornerstone of a Unix skillset. By comparison, I often forget the custom syntax of my custom scripts I wrote years ago.
    • confluence 14y ago
      I can write complex vector math in C from memory - doesn't mean everyone needs to be able to do it. That replace library does what it's supposed to do - it replaces shit easily. Don't like it - don't use it. If people want to do more - then they'll figure it out for themselves. For everyone who already knows more - eat some humble cake.
      • lobotryas 14y ago
        >Don't like it - don't use it. This is a false dilemma and completely misses the point. The replace library was written by a person who either never heard of or never learned how to use SED. Just because they created their own hack as a workaround doesn't mean it's the right thing to do.
• TylerE 14y ago
  I can think of no better advertisement for replace than this post.
• doktrin 14y ago
  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 probably take me 5-10 minutes of scanning the man pages to reproduce all but the simplest of those snippets. Granted, this boils down to the sporadic use-case, but that's the entire point. The replace examples are all clean. It would mean I would not be juggling little peculiarities of arcane syntax, such as which sed flags to invoke, or whether to use exec or xargs.
  • 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."
• wereHamster 14y ago
  sed -i the way you use it is not portable. BSD (and therefore Mac OS X) requires a mandatory argument to -i (the suffix to use for the backup files). In Linux sed the suffix is optional.
• aaronh 14y ago
  I don't even get what the issue is. People have a problem that she even wrote this? I wrote something similar because there IS no standard replace tool along the lines of grep. Sed is awful (it's essentially impossible) for multiline expressions for example. Could this really be penis measuring because people think they are so cool that they know unix commands exist? Congratulations, you have turn invocations of a simple, convenient tool into a shitpile trainwreck of find and sed. Golf claps for infinity.
• readme 14y ago
  There's another reason to reinvent the wheel: $ replace "Foo" "Bar" is common sense and easy to understand. Not to mention that sed -i is a GNU extension. I haven't used replace but it seems like a pretty innocent piece of helpful code for someone who likes JS.
  • gilmeir 14y ago
    I agree and also I took a peek at the code and my eyes did not bleed... it's a nice little one-off that doesn't try to do too much and is written in a decent ad-hoc manner... what's wrong with that? Heather, you've created a nice and useful tool with a modern tool-set, did a very decent job coding it and took the time to open-source it. In my eyes at least it puts you in the top 0.01% of coders in the world.
  • mpyne 14y ago
    I actually had something similar myself, a shell function called findRE, the entire purpose of which was to automate searching a given path recursively for a given regex. However I used it so infrequently that whenever the need would arise, I would invariably screw up the order of the 2 (only 2!) arguments. I could have added support for --help, --usage or similar, but that seemed like overkill. I eventually just learned how to "properly" use find and grep (both of which I was already using anyways, which helped me remember the command line for each). With that said I do agree that I'd never use shell script or Unix userland on purpose when writing scripts that are intended to be portable across different Unices (or even Windows), that's the kind of thing I'd reserve for personal use on my own userland. Hell, even on one machine you never know with some distributions what kind of shell you'll login to by default...
    • deleted 14y ago
      [deleted]
• SomeCallMeTim 14y ago
  >If you care about simplicity, I would personally rather write a small shell script wrapping find/xargs/sed and hiding their arcane options, as opposed to writing 173 lines of js. I would rather use my language of choice to implement the above (mine wouldn't be JavaScript, but it clearly was Heather's) than to research all of those arcane command lines. Rather obviously YOUR language of choice for this kind of problem IS sed. So OF COURSE you would use a shell script wrapping sed etc. to implement these functions. But guess what? To handle all of those options at the command line would still take a pretty large fraction of 173 lines of code, if you added in an equivalent level of parameter checking and option handling. And if you want to make MY eyes bleed, hand me a file with ~150 lines of logic in shell script that spawns cryptic command lines. Despite not REALLY knowing JavaScript, I would much prefer to maintain the JavaScript than a shell script with the above commands.
  • mrb 14y ago
    I believe that your complexity estimate in writing the wrapper indicates you are perhaps not a proficient shell scripter. However I sincerely believe it is possible to write such a wrapper in less than 15-20 lines. The trick is to do as little argument parsing as possible but enough to be safe (for example pass the ! -name "*.min.js" as is to find). PS: I will do it in 15-20 lines, if only to prove a point, if someone sends 1 BTC to 1F43fceWvwznv4rH7s1B3du2w5VznFJY58 :) (yes, my time is valuable - I have other things to do)
    • SomeCallMeTim 14y ago
      No interest in seeing a proof of concept. And I make no claims about being a "proficient" shell scripter: You've nailed me there. I can write a shell script if I absolutely have to, but I avoid it when possible since Bash is such a terrible "language." When I DO see non-trivial shell scripts, they are just this side of arcane gibberish. The command lines above are completely opaque to anyone but an expert in EACH of those tools (I know some of the tools, but not all well enough to know EXACTLY when I need to backslash a paren, or how many backslashes to use, or when I need quotes or not...). When I see the JavaScript that spawned this conversation, despite not knowing JavaScript well at all (probably about the same level I "know" shell scripting) I was able to follow everything that was happening to the point where tweaking it to add features would have been easy. The objective shouldn't be to write code in the fewest possible symbols. Everyone would use APL (or a more recent evolution of that language) if that were the case. The fewest possible readable and modifiable lines of code is my objective. Shell scripting tends to have lots of obscure and unpleasant syntax to accomplish the most basic flow control.
• kamaal 14y ago
  You have a valid point but its incomplete, allow me to explain you why we need projects like replace. You are right in telling that sewing a few utilities using pipes can emulate 'replace'. But remember you are talking about learning those 'few' utilities first. Trust me unless you have practiced your way out of these thing with hundreds of hours with experience over years its humanly impossible to remember and use a tool like sed to its full capacity. The more utilities you add to your pipe chain the number of ways in which these utilities can be used more or less follows a exponential curve. Now if some one comes along and gives you a version 1 of a tool that can simplify these things and give you simple way of doing things in a command instead of doing it with a ten pipe chain commands, he/she is ideally solving a problem of a great importance. As some one who loves the Unix CLI, I have often wondered why people spend a whole day writing a java program what could have easily done with sed and awk in a line or two. But these days I understand why. Learning and using sed/awk to their full potential is a time consuming task. You not only have to learn them factually through a manual. You also need to study the problem cases for which they are appropriate. Then you need to go and put their solution patterns in your brain. Then you need to map all problem patterns with solution patterns. Then you need to learn all the arcane special cases. Generally this comes to a person over years practicing those utilities. As a matter of fact Perl was invented because using C, with all these utilities was getting very difficult. Now if somebody can give things like these. Which do many things out of the box, without you having to go through the pain of learning things and practicing over the years. They would have indeed given you a tool of great value. In my experience even if some one fails working on something like this, by third or fourth version of the tool they generally come up with a thing of great value. Think of this like Vim Vs Sublime Text 2. In case of vim there are ways of solving problems. In ST2 many of those solutions are automated and sometimes given to you out of the box.
  • webreac 14y ago
    I have just publish a report on monday where I explain that the command line should be used instead of some small scripts that encapsulate for loops. The argument is that basic shell knowledge should be trained in order to not lose skill (or to improve). At my work, these skills are useful when facing unexpected urgent needs. Having a short script is a very poor benefit (simpler syntax and reduced key typing) for a big loss: - loss of knowledge - loss of understanding of what the script is doing - need to learn the name of the script which is not a reusable knowledge. Learning the basic usage of sed, awk, shell is an investment that is quickly rewarded. Learning all the intricacy of "replace" needs to know many javascript details and how they interact with shell escape sequences and your LOCALE configuration. I am sure it is less documented than the sed command.
• btilly 14y ago
  both Perl and Python use PCRE No, Perl doesn't. PCRE was written because a lot of people liked some of the ideas that were first introduced in Perl's regular expression engine. But PCRE was a reimplementation, and never was all that compatible with what Perl was doing.
  • LeonidasXIV 14y ago
    The funny thing is, that Python doesn't use PCRE either and never had.
    • muyuu 14y ago
      True enough. It's not the first time I hear about PCRE and Python, so maybe it's a common misconception. Other than "re", there's "re2" and "regex". None are PCRE but "regex" is close enough most of the time.
• shazow 14y ago
  Thank you for taking the time to write these translations. In fact, I'm going to bookmark this thread and use it as a reference in the future. I feel these examples serve more as a selling point for why one would use something like `replace` over a cacophony of flags and pipes. The interface for `replace` is simple and elegant. It does one thing, and it does it well. I think that's commendable. P.S. The `sed -r` flag does not exist on POSIX systems like OSX. You'll have to use something like perl -pie, or write a convoluted buffering loop.
  • aidenn0 14y ago
    Or install gnu sed
• pretoriusB 14y ago
  >I took every single example from your README, and show you below how everything can be reimplemented with sed -r (nice extended regex syntax, mostly like js regexs), and find/xargs: And why assume a POSIX command line?
• benologist 14y ago
  Hers is concise and elegant. sed and find are just defaults.
• PhantomLobe 14y ago
  find . -type f -print0 | xargs -0 sed -ri 's,var,let,g' Could better be find . -type f -exec sed -i 's/var/let/g' {} \;
• aneth4 14y ago
  The clear answer is probably appreciated however the implication that reimplementing something needs to be "justified" is absurd, even setting aside the fact that the syntax you use is representative of the arbitrary, inconsistent, and generally horrible CLI of unix commands, and does not represent a good case against implementing a better interface. Open source is packed to the brim with "reimplementations," some out of ignorance, some for learning, some to improve, some to port to different languages, some for ego, some for principal, and some for many other reasons. Frankly the code is hardly deserving of derision. It looks perfectly capable to me, and the syntax is far superior to arcane unix commands. Just because you'd rather write a sed wrapper than write this code doesn't mean it makes sense to deride others for trying to move the human race forward.
• mrb 14y ago
  Some of my examples can be further simplified (no -print0, no xargs), without a perf issue ("{} +" passes multiple filenames as arguments), with GNU find which is standard on Linux: replace 'var' 'let' . -r find . -type f -exec sed -ri 's,var,let,g' {} + replace 'var' 'let' . -r --include="*.js" find . -type f -name '*.js' -exec sed -ri 's,var,let,g' {} + replace 'var' 'let' . -r --exclude="*.min.js,*.py" find . -type f ! -name '*.min.js' ! -name '*.py' -exec sed -ri 's,var,let,g' {} + To all the Unix shell critics: don't try to argue that writing a 173-line js script is "simpler" than learning 3 find options (-type -name -exec), the bang(!) 'not' operator in find, and 2 sed options (-r -i). This is just wrong, seriously.
  • acqq 14y ago
    You are still wrong, she is still right. If we wouldn't have to care about either 1) the resource use or 2) the easiness of use, then most of the programming would be unnecessary. Her solution is better than yours on 2) always, and on 1) as soon as you need that functionality in node.js contexts.
    • mrb 14y ago
      You are wrong about #1: her design goal was use from the command line (according to her readme), not from node.js. You are wrong about #2 too: I have said this 5 times already: you can write a very short (much shorter than 173 lines of js) a wrapper shell script exposing an interface as easy as "replace". Please read what I wrote!
      • acqq 14y ago
        Even if she designed it to be used from the command line, and this is still not the only possible use of the JavaScript code which she open sourced, she had one more reason: sed doesn't have JavaScript regexps. Anybody who really wants to use JavaScript regexps doesn't have other choice but to use her tool. Now you can say that you don't need that, but you still has to admit that others may. So you're still wrong.
        • 14y ago
• ananthrk 14y ago
  In his(her?) own words: http://harthur.wordpress.com/2011/06/06/replace/ http://harthur.wordpress.com/2011/06/06/replace/
  • peejaybee 14y ago
    Ironic that the post just before that on her blog is about dealing with the assholes you will likely encounter in Open Source.
• Tichy 14y ago
  I think it can be valid to do stuff with a scripting language you know, rather than shell commands (isn't that the good old Perl philosophy?). I've actually even looked up sed once and did stuff with it, but it doesn't come up often enough to remember the gory details. And learning sed just to replace stuff takes too much time. That said, the javascript solution does look a bit long winded. Also, please don't take it as a negative comment on your comment, I actually appreciate the solutions and it makes me consider sed again.
• ecdavis 14y ago
  Why are people so opposed to reinventing the wheel? In a professional context, I understand[1], but this is a personal project someone wrote to scratch their own itch. Why is it unjustifiable? I can think of plenty of reasons to reimplement something but I think the burden is really on you to say why it shouldn't be done. If you think replace is a waste of time just don't use it - simple as that. [1] I've spent the last two years maintaining an application written in a homegrown web framework - don't get me started.
• Tyr42 14y ago
  Replace looks better to me. I can figure out the command line options from just looking at them, and it does what I expect. I like it.
• thinklarge 14y ago
  Very nicely done. It was cool that you outlined this in a lesson format and pointed to how things could have been done differently and attempted to show the perspective of the commenter. Talk about constructive input.
• randiSP 14y ago
  I've been working in software companies for a few years and I could say that something like this "replace" application is pretty much useful: - Node.js can be installed on Windows and sed/find are not available on this platform. - Many of my coworkers don't understand sed/find syntax, and even if they could learn it, they don't have plenty of time. Btw, it's terrible that a few guys make rude comments about a free and open source software. If you don't like, don't use it or if you think you can make it better, fork it or shut up.
• bane 14y ago
  The good news is that in every single example, her command-line equivalent is fewer keystrokes (sometimes many fewer). Depending on how much you need to this sort of workflow, this could be extremely valuable.
• PeterisP 14y ago
  You just made a point why this 'replace' may actually be useful to do things instead of bothering with using something as needlessly complicated as you have illustrated sed. It would be far quicker for me to write an one-use program in a number of languages than to find out how to do this in the sed oneliner style that you show - ergo, the sed approach has drawbacks in some use cases, and alternatives should be tried.
• KorvinSzanto 14y ago
  I would rewrite these functions for fun, even with an understanding of them. It doesn't matter if the end result is useful or not, we're programmers, we enjoy programming, not using. Of course that's to a point; time spent making something useful that's fun to make is more rewarding to most. I'm just making the point that it's not just about learning, it's about writing the code. If you're the type of programmer that is only looking for a means to an end, this isn't for you, but if you're like me, the fun is in figuring it out yourself without the help of libraries.
• mattdeboard 14y ago
  ack-grep does quite a lot of this as well.
• Osiris 14y ago
  Why are people even arguing about this? Is there some religion that forces people to only believe in and use GNU tools that they can't appreciate a competing tool? A tool's a tool. If it's useful to you, use it. If you don't need it, then don't. Why does this have to turn into a debate about why someone shouldn't have invented another tool because one already exists? Look around the world, there's competition and choice in literally everything. Why can't they be choice in what CLI tools to use?
• VikingCoder 14y ago
  I guess I'll point out that if you want to play "golf", the replace command was shorter in every single one of your examples.