4 ms·

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

by 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.
    - mrb 14y ago
      With all due respect, you add nothing to the discussion, I already acknowledged this in my OP: "There is only one case that justifies reimplementing things: if your tool has the requirement of supporting the exact js regex syntax..." (Please read what I wrote, really!)
      - acqq 14y ago
        a) Can you agree that the main reason of open sourcing a JavaScript code is for others to use the same code in their projects, not to "run the command line"? b) Regarding those that do want to "run the command line," can you agree that there are users who really want and need to use JavaScript regexps from the command line and not some other regexps with different semantics? c) Can you accept that these are the valid use cases that your "use sed" arguments just don't cover? I've read your arguments and I've never seen clear acceptance of a) b) and c). I've also seen that you had to carefully think and even improve your "use sed" implementations, giving also the good argument in favor of her approach. Having the tools that demand less from the user is a good thing. Can you accept that (d) too? Can you see why we discuss, when you just quote yourself as "There is only one case"? That's why I claim you're wrong. There's not only one case.
gabemart 14y ago
>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). In the context of discussing the open-sourcing of the script, the issue isn't really whether or not writing the JS is simpler than learning "3 find options", it's whether using the JS is simpler than learning "3 find options".
muyuu 14y ago
You don't need to write a 173 line js script, in the same way you don't need to write the thousands of lines of C code behind find or sed. You just use it. Let's face it. Most people will never bother learning shell commands in and out. I've been a *nix user for 20 years and I still have to be checking man pages, and I often stumble upon basic shell command options running differently in different shells. Other than for sysadmins, shell commands are going the way of the dodo. This isn't new, it's been happening for many years already. Increasingly capable computer people from the newer generations will be focusing their skills and time elsewhere. Arguing against this reeks of grumpy old coder bitterness. I know my shell stuff and it serves me well. I use vi/vim daily. I don't impose my usage patterns or expect that something "existing" means it's appropriate for everybody.

by mrb 14y ago

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.
  - mrb 14y ago
    With all due respect, you add nothing to the discussion, I already acknowledged this in my OP: "There is only one case that justifies reimplementing things: if your tool has the requirement of supporting the exact js regex syntax..." (Please read what I wrote, really!)
    - acqq 14y ago
      a) Can you agree that the main reason of open sourcing a JavaScript code is for others to use the same code in their projects, not to "run the command line"? b) Regarding those that do want to "run the command line," can you agree that there are users who really want and need to use JavaScript regexps from the command line and not some other regexps with different semantics? c) Can you accept that these are the valid use cases that your "use sed" arguments just don't cover? I've read your arguments and I've never seen clear acceptance of a) b) and c). I've also seen that you had to carefully think and even improve your "use sed" implementations, giving also the good argument in favor of her approach. Having the tools that demand less from the user is a good thing. Can you accept that (d) too? Can you see why we discuss, when you just quote yourself as "There is only one case"? That's why I claim you're wrong. There's not only one case.

gabemart 14y ago

>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). In the context of discussing the open-sourcing of the script, the issue isn't really whether or not writing the JS is simpler than learning "3 find options", it's whether using the JS is simpler than learning "3 find options".

muyuu 14y ago

You don't need to write a 173 line js script, in the same way you don't need to write the thousands of lines of C code behind find or sed. You just use it. Let's face it. Most people will never bother learning shell commands in and out. I've been a *nix user for 20 years and I still have to be checking man pages, and I often stumble upon basic shell command options running differently in different shells. Other than for sysadmins, shell commands are going the way of the dodo. This isn't new, it's been happening for many years already. Increasingly capable computer people from the newer generations will be focusing their skills and time elsewhere. Arguing against this reeks of grumpy old coder bitterness. I know my shell stuff and it serves me well. I use vi/vim daily. I don't impose my usage patterns or expect that something "existing" means it's appropriate for everybody.