31–40 of 66 posts
for i in $(seq 1 20); do
(run once and emit the total CPU time)
done |addup
This is slower than not running seq and just using builtins.
n=1;while true;do
test $n -le 20||break;
(run once and emit the total CPU time)
n=$((n+1));
done |addupEarlier quoted context omitted.
sed 's| no | not only |'
/bin/bash won't usually ship with a BSDish OS because of the license, so it is not generally portable to use bash-isms. (HPUX, IRIX, SunOS, Solaris, etc. I don't reckon would have had bash either)
Earlier quoted context omitted.
That's the whole point of shell scripting, to take a series of minimal programs and tie them together into something that does a more complex task. There's no reason to distrust a shell script simply because it is a script any more than there is to trust a binary simply because it's a binary.
Sure, but relying on custom shell scripts as unix primitives can be problematic if you find yourself frequently managing/troubleshooting systems that you don't own, and you don't want to (or aren't allowed to) put those handy scripts in place. Then when you're on any given system, you forget whether you can use "f", or if you have to fall back on awk. I think it's less about not trusting custom scripts than it is abo…
I spend a lot of time moving around different machines, processes, configuration files, logs, etc. And I stopped maybe 10 years ago to use anything that is not available on a base system.
I don’t use fancy shells, I don’t use aliases, I don’t write local shortcut scripts, etc.
I just use regular bash, combine base utilities in one liners, and live with it.
Maybe I loose 1s here and there when writing one liners compared to someone with a library of wrapper utilities. But that gives me an immense benefit: I am at home on any machine, any distribution, everywhere, without any configuration, with any user.
Earlier quoted context omitted.
Sure, but relying on custom shell scripts as unix primitives can be problematic if you find yourself frequently managing/troubleshooting systems that you don't own, and you don't want to (or aren't allowed to) put those handy scripts in place. Then when you're on any given system, you forget whether you can use "f", or if you have to fall back on awk. I think it's less about not trusting custom scripts than it is abo…
> if you find yourself frequently managing/troubleshooting systems that you don't own You start thinking about packaging .
I would be mad at any admin that would dare to deploy his helper shell scripts like “addup” and “count” on a machine other than his laptop.
And if you meant he could just have these things in his home, then it defeats the purpose of the original comment: trouble shooting and administering machines forces you to often switch user, machine, etc.
Earlier quoted context omitted.
Not exactly. sort (at least GNU sort) will end up doing external merge sort on temporary files if you give it more data than you have memory. Which, if you give it 100GB of 5 different strings, ends up being a huge waste.
Not only GNU sort, but also postgresql, mysql and many more... Please, "huge waste"? How do you sort something that does not fit in memory?
I posted a comment on how 'sort | uniq -c | sort -n' is an interesting and very capable pipeline, but often misused and slower than other alternatives.
> you are comparing
Yes, I am comparing two methods of accomplishing the same thing. That is how comparing things works.
> Please, "huge waste"? How do you sort something that does not fit in memory?
Note how the full sentence included "if you give it 100GB of 5 different strings". If your input is 100GB of 5 different strings, then the hash table will easily fit in memory, and sorting the entire data set only to pass it to 'uniq -c' is indeed a 'huge waste'.
There are tons of large data sets that only have a small number of unique values in particular fields. protocols, ports, http status codes, hour of the day, etc. 'sort | uniq -c | sort -n' will work for all of them, but not nearly as efficient a hash table.
Earlier quoted context omitted.
Sure, but relying on custom shell scripts as unix primitives can be problematic if you find yourself frequently managing/troubleshooting systems that you don't own, and you don't want to (or aren't allowed to) put those handy scripts in place. Then when you're on any given system, you forget whether you can use "f", or if you have to fall back on awk. I think it's less about not trusting custom scripts than it is abo…
I agree 100% with you. I spend a lot of time moving around different machines, processes, configuration files, logs, etc. And I stopped maybe 10 years ago to use anything that is not available on a base system. I don’t use fancy shells, I don’t use aliases, I don’t write local shortcut scripts, etc. I just use regular bash, combine base utilities in one liners, and live with it. Maybe I loose 1s here and there when w…
for i in $(seq 1 20); do (run once and emit the total CPU time) done |addup "Here we don't actually care about the output (we never actually use $i) but it's a convenient way to get the for loop to run twenty times." This is slower than not running seq and just using builtins. n=1;while true;do test $n -le 20||break; (run once and emit the total CPU time) n=$((n+1)); done |addup
If you don't want the inefficiencies of seq, bash has:
for (( expr1 ; expr2 ; expr3 )) ; do list ; done
Earlier quoted context omitted.
I agree 100% with you. I spend a lot of time moving around different machines, processes, configuration files, logs, etc. And I stopped maybe 10 years ago to use anything that is not available on a base system. I don’t use fancy shells, I don’t use aliases, I don’t write local shortcut scripts, etc. I just use regular bash, combine base utilities in one liners, and live with it. Maybe I loose 1s here and there when w…
There's always something like Ansible (or even a lower-tech solution) to at least give you the basic toolset that helps you double or triple your performance.
Sure, in a quest of productivity, I should also use Vagrant and Packer to create docker images with a development environment so that I can run Serverless troubleshooting containers on all my machines.
These scripts will surely help me triple the performance of my bash one liners.
I’ve heard Eclipse has good shell completion and support for oh-my-zsh too.
Earlier quoted context omitted.
> if you find yourself frequently managing/troubleshooting systems that you don't own You start thinking about packaging .
Packaging what? I would be mad at any admin that would dare to deploy his helper shell scripts like “addup” and “count” on a machine other than his laptop. And if you meant he could just have these things in his home, then it defeats the purpose of the original comment: trouble shooting and administering machines forces you to often switch user, machine, etc.
Then instead of having to remember how to check all these things, they just run "find_resource_hogs.sh" and voila. It also enables other people to troubleshoot without specific knowledge.
Of course you don't want to put anything in there just because it might save 10 seconds, but then https://xkcd.com/1205/
for i in $(seq 1 20); do (run once and emit the total CPU time) done |addup "Here we don't actually care about the output (we never actually use $i) but it's a convenient way to get the for loop to run twenty times." This is slower than not running seq and just using builtins. n=1;while true;do test $n -le 20||break; (run once and emit the total CPU time) n=$((n+1)); done |addup
The author did say convenient , not fast. If you don't want the inefficiencies of seq, bash has: for (( expr1 ; expr2 ; expr3 )) ; do list ; done which is a lot more idiomatic than constructing a for loop out of a while loop.
for i in {1..20}
do
...
done