Hacker Newsnew | past | comments | ask | show | jobs | submit | csours's commentslogin

Regarding "Conspiracy Theories" - they make a lot more sense to me if you call them "Low Information, High Satisfaction" Theories.

Regarding the rest of the article: it reminds me of how things like nursery rhymes or fairy tales or Shakespeare's plays used to mean something very different and very specific.


The conveniences also mean that there is more than ~one~ ~two~ several ways to do something.

Which means that reading someone else's shell script (or awk, or perl, or regex) is INCREDIBLY inconvenient.


Yes. There are many reasons why one shouldn't use sh/bash for scripting.

But my main reason is that most scripts break when you call them with filenames that contain spaces. And they break spectacularly.


Counter reason in favor is that you can always count on it being there and working the same way. Perl is too out of fashion and python has too many versioning/library complexities.

You have to write the crappy sh script once but then you get simple, easy usage every time. (If you're revising the script frequently enough that sh/bash are the bottleneck, then what you have is a dev project and not a script, use a programming language).


You're not wrong, but there's fairly easy ways to deal with filenames containing spaces - usually just enclosing any variable use within double quotes will be sufficient. It's tricker to deal with filenames that contain things such as line breaks as that usually involves using null terminated filenames (null being the only character that is not allowed in filenames). e.g find . -type f -print0

You're not wrong, but at my place, our main repository does not permit cloning into a directory with spaces in it.

Three factors conspire to make a bug:

  1. Someone decides to use a space
  2. We use Python
  3. macOS
Say you clone into a directory with a space in it. We use Python, so thus our scripts are scripts in the Unix sense. (So, Python here is replacable with any scripting language that uses a shebang, so long as the rest of what comes after holds.) Some of our Python dependencies install executables; those necessarily start with a shebang:

  #!/usr/bin/env python3
Note that space.

Since we use Python virtualenvs,

  #!/home/bob/src/repo/.venv/bin/python3
But … now what if the dir has a space?

  #!/home/bob/src/repo with a space/.venv/bin/python3
Those look like arguments, now, to a shebang. Shebangs have no escaping mechanism.

As I also discovered when I discovered this, the Python tooling checks for this! It will instead emit a polyglot!

  #!/bin/bash

  # <what follows in a bash/python polyglot>
  # the bash will find the right Python interpreter, and then re-exec this
  # script using that interpreter. The Python will skip the bash portion,
  # b/c of cleverness in the polyglot.
Which is really quite clever, IMO. But, … it hits (2.). It execs bash, and worse, it is macOS's bash, and macOS's bash will corrupt^W remove for your safety! certain environment variables from the environment.

Took me forever to figure out what was going on. So yeah … spaces in paths. Can't recommend them. Stuff breaks, and it breaks in weird and hard to debug ways.


If all of your scripts run in the same venv (for a given user), can you inject that into the PATH and rely on env just finding the right interpreter?

I suppose it would also need env to be able to handle paths that have spaces in them.


What a headache!

My practical view is to avoid spaces in directories and filenames, but to write scripts that handle them just fine (using BASH - I'm guilty of using it when more sane people would be using a proper language).

My ideological view is that unix/POSIX filenames are allowed to use any character except for NULL, so tools should respect that and handle files/dirs correctly.

I suppose for your usage, it'd be better to put the virtualenv directory into your path and then use #!/usr/bin/env python


For the BSDs and Linux, I believe that shebang are intepreted by the kernel directly and not by the shell. /usr/bin/env and /bin/sh are guaranteed by POSIX to exists so your solution is the correct one. Anything else is fragile.

These are part of the rituals of learning how a system works, in the same way interns get tripped up at first when they discover ^S will hang an xterm, until ^Q frees it. If you're aware of the history of it, it makes perfect sense. Unix has a personality, and in this case the kernel needs to decide what executable to run before any shell is involved, so it deliberately avoids the complexity of quoting rules.

I'd give this a try, works with any language:

  #!/usr/bin/env -S "/path/with spaces/my interpreter" --flag1 --flag2
Only if my env didn't have -S support, I might consider a separate launch script like:

  #!/bin/sh
  exec "/path/with spaces/my interpreter" "$0" "$@"
But most decent languages seems to have some way around the issue.

Python

  #!/bin/sh
  """:"
  exec "/path/with spaces/my interpreter" "$0" "$@"
  ":"""
  # Python starts here
  print("ok")
Ruby

  #!/bin/sh
  exec "/path/with spaces/ruby" -x "$0" "$@"
  #!ruby
  puts "ok"
Node.js

  #!/bin/sh
  /* 2>/dev/null
  exec "/path/with spaces/node" "$0" "$@"
  */
  console.log("ok");
Perl

  #!/bin/sh
  exec "/path/with spaces/perl" -x "$0" "$@"
  #!perl
  print "ok\n";
Common Lisp (SBCL) / Scheme (e.g. Guile)

  #!/bin/sh
  #|
  exec "/path/with spaces/sbcl" --script "$0" "$@"
  |#
  (format t "ok~%")
C

  #!/bin/sh
  #if 0
  exec "/path/with spaces/tcc" -run "$0" "$@"
  #endif
  
  #include <stdio.h>
  
  int main(int argc, char **argv)
  {
      puts("ok");
      return 0;
  }
Racket

  #!/bin/sh
  #|
  exec "/path/with spaces/racket" "$0" "$@"
  |#
  #lang racket
  (displayln "ok")
Haskell

  #!/bin/sh
  #if 0
  exec "/path/with spaces/runghc" -cpp "$0" "$@"
  #endif
  
  main :: IO ()
  main = putStrLn "ok"
Ocaml (needs bash process substitution)

  #!/usr/bin/env bash
  exec "/path/with spaces/ocaml" -no-version /dev/fd/3 "$@" 3< <(tail -n +3 "$0")
  print_endline "ok";;

Ah, but then there are the unusual cases. See “The shell and its crappy handling of whitespace.”

https://blog.plover.com/Unix/whitespace.html


If you need to know what 2>&1 means, then I would recommend shellcheck

It's very, very easy to get shell scripts wrong; for instance the location of the file redirect operator in a pipeline is easy to get wrong.


As someone who use LLMs to generate, among others, Bash script I recommend shellcheck too. Shellcheck catches lots of things and shall really make your Bash scripts better. And if for whatever reason there's an idiom you use all the time that shellcheck doesn't like, you can simply configure shellcheck to ignore that one.

YouTube: If you remove direct link access to by subscriptions by upload date, I will drop my premium subscription and watch time drastically.

this pairs nicely with the finding of the supreme court:

    Under our constitutional structure of separated powers, the nature of Presidential power entitles a former President to absolute immunity from criminal prosecution for actions within his conclusive and preclusive constitutional authority. And he is entitled to at least presumptive immunity from prosecution for all his official acts. There is no immunity for unofficial acts.
https://www.supremecourt.gov/opinions/23pdf/23-939_e2pg.pdf

Or that's completely unrelated?

Look, you can't have a (working, democratic) government where one party can send the other to jail as soon as they get into power. If presidents could go to jail for doing their job, their opposing party would absolutely try to send them there.

This would then ultimately handicap the president: anything they do that the opposition can find a legal justification against could land them in jail, so they won't do anything that comes close to that. We do not want our chief executive making key decisions for the country based on fear of political retribution!

The Supreme Court has failed, miserably and repeatedly lately, and some of their decisions run directly counter to the law (often they even contradict past decisions!) But deciding the president won't face political retribution for trying to do his job was not a mistake.


Hard disagree. The metric ought to be whether they'll make it out of the court case clean or not - just having the ability to check power in a meaningful fashion when it goes off the rails is something you're only afraid of if you're a war criminal or other flavor of Massive Piece Of Shit.

The reason the rules are the way they are is pretty obvious; we haven't had a not war criminal in office possibly ever, definitely not in my lifetime. It's time we faced the facts - we're the baddies.


This is a really silly take. The whole reason for separation of powers is so that the executive can be bound by laws created by the legislative as adjudicated by the judiciary. Saying that the people in the executive are above the law undermines this completely.

This doesn't say the executive is above the law, it says you can't prosecute the president for doing his job, just like you can't prosecute judges for their rulings on the bench or members of congress for their votes on the floor.

I don't really see an equivalence between those very specific and limited acts and vast swathe of things covered by "official acts" of a President.

The equivalence is that in all three cases those are the official duties of the office.

I would agree that the scope of the president's job description has gotten overly broad over the last century as congress has delegated more and more of its powers to the executive branch, but I don't think a prosecutorial Sword of Damocles is a good solution to that problem. Certainly it's not the constitutionally prescribed one anyway, which is what the court's ruling affirmed.


"Don't break the law" seems like a pretty low bar to clear for the most powerful person in the country.

Or even more lizard brain: if you have more cardio capacity/fitness, your body actually FEELS better, so you feel better emotionally and cognitively.

If you have lower capacity, your body feels bad and this is reflected in your emotional and cognitive state.


I'm 40. Do I need to get my parents to vouch for me? Who vouches for them?

> then give parents strong monitoring and restriction tools

As written, this sounds very glib. I cannot take this comment seriously without a game theory scenario with multiple actors.


Damn, that sounds like a bit that would be cut from a romantic comedy for being too on the nose.

https://www.youtube.com/watch?v=X_crwFuPht4 AlphaPhoenix - An intuitive approach for understanding electricity

Unlimited Free Speech, itty bitty living space. - Aladdin's Genie

I have no idea what this means

https://www.youtube.com/watch?v=KJ85y3q6K8c

Many people in or related to the current administration have spoken in favor of free speech, which feels quite ironic.


>Many people in or related to the current administration have spoken in favor of free speech, which feels quite ironic.

Indeed. Our government, like most governments across the world in 2026, has moved way beyond the naive notion of "free speech." Talking about it now is either nostalgia, or lies



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: