4 ms·
Why can't the hardcoded "#!.../python" lines be fixed with find+sed? I'm not sure I understand exactly what he's trying to do.
by Goladus 17y ago
Why can't the hardcoded "#!.../python" lines be fixed with find+sed? I'm not sure I understand exactly what he's trying to do.
- jnoller 17y agoI did exactly that at first; the problem is that it shouldn't need to be done, and additionally, other things (such as .pth files) can also include hardcoded paths.
- nailer 17y agoFixing it is good, but a nicer to start an interpreter, which handles whichever is the preferred location to Python, is to call env, which is always in usr bin. #!/usr/bin/env python Will dynamically start whatever Python is in your $PATH.
- Goladus 17y agoRight, I'm saying that he was faced with a group of files he couldn't tar up, because the #! were all fixed. I'm wondering why he couldn't just replace '#!.*/python' with '#!/usr/bin/env python' for everything in the tree.
- jnoller 17y agoAnd I can/could, and will probably still end up doing that as much as I might not like it - and any time you install something else which includes a script in a binpath, you need to rerun the sed command.
- LogicHoleFlaw 17y agoYou'd think /usr/bin/env would always work, but I've seen this break in production systems where /usr/bin/env is not in the $PATH in situations like cron scripts. It's retarded I know but it does happen.
- jrockway 17y ago/usr/bin/env is not in the $PATH I don't think you mean this. When you specify an absolute name, $PATH is not even in the picture. (I do know that some systems put env in /bin. Those systems are misconfigured.) Anyway, shebangs are flaky by design. I just run the correct interpreter directly, as in "/path/to/perl -Ilib bin/script.pl". There is no confusion that way.
- nailer 17y agoYou're right - I think what he means is that env is not in /usr/bin. This was the case on very old (Red Hat Linux 5.2 back in the late 90s) systems where there was no /usr/bin/env -> /bin/env symlink.
- LogicHoleFlaw 17y agoI was bit confused in my description here, sorry. /usr/bin/env existed but when it was run under the cron user's environment it could not locate the interpreter we required and failed silently. The shebang line worked fine under all other users' accounts. Very frustrating. I assume this problem was due to the cron account's $PATH being set up differently somehow. In any case we just went back to explicitly choosing our site-specific interpreter path. Related pet peeve: people using #!/bin/sh when they really want #!/bin/bash. They are not interchangeable!
- nailer 17y agoThose systems are broken - user binaries are non-critical binaries for everyone. There are more binaries in this location than anywhere else.