191–200 of 388 posts
Debugging Linux pipelines is not a fun experience. This is one clear area where Powershell with its object model has got it right.
Please provide an example. Thank you.
https://docs.microsoft.com/en-us/powershell/module/microsoft...
Interesting comment in the header of this site. https://github.com/prithugoswami/personal-website/blob/maste...
It's a meme: https://www.reddit.com/r/copypasta/comments/5we0ny/if_youre_...
Earlier quoted context omitted.
Please provide an example. Thank you.
PowerShell supports breakpoint. https://docs.microsoft.com/en-us/powershell/module/microsoft...
This way you can watch a UNIX user "struggle/fail" as they "attempt" to debug a script using set -x, set -e, $?, LINENO, utilties like ktrace, strace, recordio, etc. and your argument will be taken seriously.
Earlier quoted context omitted.
I am firmly in the "ugh" camp. I strongly suspect that the fawning that occurs over pipelines is because of sentimentality more than practicality. Extracting information from text using a regular expression is fragile. Writing fragile code brings me absolutely no joy as a programmer - unless I am trying to flex my regex skills. If you really look at how pipelines are typically used is: lines are analogous to objects…
If you're having to extract your data using a regex, then the data probably isn't well-formed enough for a shell pipeline. It's doable, but a bad idea. Regex should not be the first hammer you reach for, because it's a scalpel. I recently wanted cpu cores + 1. That could be a single regex. But this is more maintainable, and readable: echo '1 + '"$(grep 'cpu cores' /proc/cpuinfo | tail -n1 | awk -F ':' '{print $2}')"…
return runtime.NumCPU() + 1
Earlier quoted context omitted.
Please don't ever assume you can avoid spaces and quotes. It's just a time bomb. It's like people saying you don't need to escape SQL values because they come from constants. Yes, they do... today. It's not just quoting either. It's setting the separator value and reverting it correctly. It's making sure you're still correct when you're in a function in an undefined state. It's a lot of overhead in larger projects.
Sure, but in a larger project your won’t be coding in shell script, right?
Earlier quoted context omitted.
There's a certain irony in responding to criticism of that which you're extolling by saying not to use it. And the only reason I might be pushed down that path is because the task I'm working on happens to involve filenames with spaces in them (without those spaces, the code would work fine!), because spaces are a reasonable thing to put in a filename unless you're on a Unix system.
The shell works with spaces, you just need to be careful to quote every file name. The advantage of using file names without spaces is that you can avoid the quotes.
$ exec(‘ls’, ‘-l’, ‘A B C’)
$ ls(ls::LONG, ‘A B C’)
$ ls ls::LONG, ‘A B C’
$ ls -LONG ‘A B C’
QED
Earlier quoted context omitted.
> Unix is seriously uncool with young people at the moment. Those damn kids with their loud rockn'roll music and their Windows machines. Back in my day we had he vocal stylings of Dean Martin and the verbal stylings of Linus Torvalds let me tell ya. Seriously though, I'm actually seeing younger engineers really taking the time to learn how to do shell magic, using vim, etc. It's like the generation of programmers who…
I guess I am one of the young kids who think the unix command line is wicked cool. It makes the user experience on my laptop feel so much more powerful.
Add to all that the fact that the command line allows for a lot of really easy composition and automation, and it's significantly better for me. I can hardly function on a Windows computer!
Earlier quoted context omitted.
set -e makes another pain for command that nonzero isn't mean failed (ex. diff). It changes semantics for whole script.
If by pain you mean you have to handle errors, yes, that's what you have to do. It's no different from checking the return code of functions in C.
Earlier quoted context omitted.
To criticize sh semantics without acknowledging that C was always there when you needed something serious is a bit short sighted. There are two uses of the Unix “api”: [A] Long lived tools for other people to use. [B] Short lived tools one throws together oneself. The fact that most things work most of the time is why the shell works so well for B, and why it is indeed a poor choice for the sort of stable tools desig…
There's a certain irony in responding to criticism of that which you're extolling by saying not to use it. And the only reason I might be pushed down that path is because the task I'm working on happens to involve filenames with spaces in them (without those spaces, the code would work fine!), because spaces are a reasonable thing to put in a filename unless you're on a Unix system.
In most other cases I’ve never really had a problem with “this is a place where spaces are ok” (e.g. notes, documents, photos) and “this is a place where they are not ok” — usually in parts of my filesystem where I’m developing code.
It’s fine to make simplifying assumptions if it’s your own code. Command history aside, most one liners we type at the shell are literally throwaways.
I think I was clear that they aren’t the only category of program one writes and that, traditionally on Unix systems, the counterpart to sh was C.