Live data from Hacker News

Scripts I wrote that I use all the time

evanhahn.com

371–380 of 408 posts

Re: Scripts I wrote that I use all the time

#371
Something I've long appreciated is a little Perl script to compute statistics on piped in numbers, I find it great for getting quick summaries from report CSVs.

    #!/usr/bin/perl
    # http://stackoverflow.com/a/9790056
    use List::Util qw(max min sum);
    @a=();
    while(){
        $sqsum+=$_*$_;
        push(@a,$_)
    };
    $n=@a;
    $s=sum(@a);
    $a=$s/@a;
    $m=max(@a);
    $mm=min(@a);
    $std=sqrt($sqsum/$n-($s/$n)*($s/$n));
    $mid=int @a/2;
    @srtd=sort @a;
    if(@a%2){
        $med=$srtd[$mid];
    }else{
        $med=($srtd[$mid-1]+$srtd[$mid])/2;
    };
    print "records:$n\nsum:$s\navg:$a\nstd:$std\nmed:$med\max:$m\nmin:$mm";

Re: Scripts I wrote that I use all the time

#372
post #250

I have a bunch, but one that I rarely see mentioned but use all the time is memo(1) ( https://github.com/aktau/dotfiles/blob/master/bin/memo ). It memoizes the command passed to it. $ memo curl https://some-expensive.com/api/call | jq . | awk '...' Manually clearing it (for example if I know the underlying data has changed: $ memo -c curl https://some-expensive.com/api/call In-pipeline memoization (includes the input…

[deleted]

Re: Scripts I wrote that I use all the time

#373
post #156
post #146

Earlier quoted context omitted.

Or more abstractly: post anything to the internet and people will always detail how you’re wrong. Sometimes that can be useful.

That seems to be especially true on HN. Other forums there is some of that as well, but HN it seems nearly every single comment section is like 75% (random number) pointing out faults in the posted article.

That's a sampling bias. You're not seeing the opinions of every single person who has viewed an article, just the opinions of those who have bothered to comment.

People who agree with an article will most likely just upvote. Hardly anyone ever bothers to comment to offer praise, so most comments that you end up seeing are criticisms.

Re: Scripts I wrote that I use all the time

#374
post #250

I have a bunch, but one that I rarely see mentioned but use all the time is memo(1) ( https://github.com/aktau/dotfiles/blob/master/bin/memo ). It memoizes the command passed to it. $ memo curl https://some-expensive.com/api/call | jq . | awk '...' Manually clearing it (for example if I know the underlying data has changed: $ memo -c curl https://some-expensive.com/api/call In-pipeline memoization (includes the input…

.

   #!/usr/bin/env bash
   #
   # memo(1), memoizes the output of your command-line, so you can do:
   #
   #  $ memo  | ...
   #
   # Instead of
   #
   #  $  > tmpfile
   #  $ cat tmpfile | ...
   #  $ rm tmpfile
   
   to save output, sed can be used in the pipeline instead of tee
   for example,
   
   x=$(mktemp -u);
   test -p $x||mkfifo $x;
   zstd -19  tmpfile.zst &
   |sed w$x|;
   
   # You can even use it in the middle of a pipe if you know that the input is not
   # extremely long. Just supply the -s switch:
   #
   #  $ cat sitelist | memo -s parallel curl | grep "server:"
   
   grep can be replaced with sed and search results sent to stderr
   
   tmpfile.zst;
   
   or send search results to stderr and to some other file
   sed can save output to multiple files at a time
   
   tmpfile.zst;

Re: Scripts I wrote that I use all the time

#375

Obviously, to each their own, but to me, this is an overwhelming amount of commands to remember on top of all the ones they are composed of that you will likely need to know anyway — regardless if all the custom ones exist. Like, I'd have to remember both `prettypath` and `sed`, and given that there's hardly any chance I'll not need `sed` in other situations, I now need to remember two commands instead of one. On top…

For someone using sed often enough inventing prettypath won't make sense. However, if producing correct sed command, be it by remembering the options, reading manual or digging through the shell history, takes some amount of mental effort, your brain will happily stick "prettypath" into memory as long as doing so stays less mentally taxing than doing original task from scratch.

Re: Scripts I wrote that I use all the time

#376
post #342

Earlier quoted context omitted.

They specifically mentioned service accounts. If they’re given an user account to login as, they still might have to get into and use the service account, and its environment, from there. If the whole purpose was to get into the service account, and the service account is already setup for remote debug, then the client might prefer to skip the creation of the practically useless user account.

That's still not professional, but then again 99.9% of companies aren't.

Could you help me understand what assumptions about the access method you have in place that make this seem unprofessional?

Let's assume they need access to the full service account environment for the work, which means they need to login or run commands as the service account.

This is a bit outside my domain, so this is a genuine question. I've worked on single user and embedded systems where this isn't possible, so I find the "unprofessional" statement very naive.

Re: Scripts I wrote that I use all the time

#378
Love it! I'll absolutely be borrowing some of these :)

On every machine of mine I tend to accumulate a bunch of random little scripts along these lines in my ~/.local/bin, but I never seem to get around to actually putting them anywhere. Trying to knock that habit by putting any new such scripts in a “snippets” repo (https://fsl.yellowapple.us/snippets); ain't a whole lot in there yet, but hopefully that starts to change over time.

Re: Scripts I wrote that I use all the time

#379
post #28

Earlier quoted context omitted.

I'd love to see a cost benefit analysis of the author's approach vs yours, which includes the time it took the author to create the scripts, remember/learn to use them/reference them when forgetting syntax, plus time spent migrating whenever changing systems.

why is this interesting to you? the whole point of doing all of this is to be more efficient in the long run. of course there is an initial setup cost and learning curve after which you will hopefully feel quite efficient with your development environment. you are making it sound like it is not worth the effort because you have to potentially spend time learning "it"? i do not believe that it takes long to "learning"…

Because some of them OP said they use a few times a year. This means they'll probably use it like 150 times in their life. If it saves a minute each time, but it takes 5 hours to create it and 5 hours to maintain it over the years, then it's not really a win.

Re: Scripts I wrote that I use all the time

#380

Earlier quoted context omitted.

It's interesting because there's a significant chance one wastes more time tinkering around with custom scripts than saving in the long run. See https://xkcd.com/1205/ For example. The "saves 5 seconds task that I do once a month" from the blog post. Hopefully the author did not spend more than 5 minutes writing said script and maintaining it, or they're losing time in the long run.

Maybe, but 1. even if it costs more time, it could also save more annoyance which could be a benefit 2. by publishing the scripts, anyone else who comes across them can use them and save time without the initial cost. similarly, making and sharing these can encourage others to share their own scripts, some of which the author could save time with

In my experience, it's not "maybe" but "almost certainly" which is why I stopped doing this. Every time I get a new system I would have to set everything up again, it's not cross platform, doesn't work when using someone else's computer, suddenly breaks for some reason or another, or you forget it exists...

The annoyance of all these factors for outweighs the benefits, in my experience. It's just that the scripts feel good at first and the annoyance doesn't come until later and eventually you abandon them.

Post reply on HN