alt Hacker NewsYou'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
#!/usr/bin/env python3
Since we use Python virtualenvs,
#!/home/bob/src/repo/.venv/bin/python3
#!/home/bob/src/repo with a space/.venv/bin/python3
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.
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.
Replies
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
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
#!/bin/sh
exec "/path/with spaces/my interpreter" "$0" "$@"
Python
#!/bin/sh
""":"
exec "/path/with spaces/my interpreter" "$0" "$@"
":"""
# Python starts here
print("ok")
#!/bin/sh
exec "/path/with spaces/ruby" -x "$0" "$@"
#!ruby
puts "ok"
#!/bin/sh
/* 2>/dev/null
exec "/path/with spaces/node" "$0" "$@"
*/
console.log("ok");
#!/bin/sh
exec "/path/with spaces/perl" -x "$0" "$@"
#!perl
print "ok\n";
#!/bin/sh
#|
exec "/path/with spaces/sbcl" --script "$0" "$@"
|#
(format t "ok~%")
#!/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;
}
#!/bin/sh
#|
exec "/path/with spaces/racket" "$0" "$@"
|#
#lang racket
(displayln "ok")
#!/bin/sh
#if 0
exec "/path/with spaces/runghc" -cpp "$0" "$@"
#endif
main :: IO ()
main = putStrLn "ok"
#!/usr/bin/env bash
exec "/path/with spaces/ocaml" -no-version /dev/fd/3 "$@" 3< <(tail -n +3 "$0")
print_endline "ok";;
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.