spack path length too long for Python scripts that use #! about spack

[tgamblin]

@lee218llnl we could get rid of 42 characters of that particular path by getting rid of the prefix. e.g., we could install by default into $spack/opt/spack/. The only problem is that you lose human readability that way. That could be solved with Matt's views. I had thought about making a minimal install location, and using views for actually browsing, but it seemed like we could get the best of both worlds.

I know @mplegendre likes the default paths. @mplegendre: any thoughts on this? Looks like the default length for shebang paths in Linux is 128 bytes 👎 http://lxr.free-electrons.com/source/include/uapi/linux/binfmts.h#L18

[jprotze]

The alternative would be using some wrapper script to handle oversized
shebangs as in:

http://stackoverflow.com/questions/10813538/shebang-line-limit-in-bash-and-linux-kernel

• Joachim

Am 09.06.2015 um 13:43 schrieb Todd Gamblin:

@lee218llnl https://github.com/lee218llnl we could get rid of 42
characters of that particular path by getting rid of the prefix. e.g.,
we could install by default into $spack/opt/spack/. The only problem is
that you lose human readability that way. That could be solved with
Matt's views. I had thought about making a minimal install location, and
using views for actually browsing, but it seemed like we could get the
best of both worlds.

I know @mplegendre https://github.com/mplegendre likes the default
paths. @mplegendre https://github.com/mplegendre: any thoughts on
this? Looks like the default length for shebang paths in Linux is 128
bytes 👎
http://lxr.free-electrons.com/source/include/uapi/linux/binfmts.h#L18

—
Reply to this email directly or view it on GitHub
#54 (comment).

Dipl.-Inf. Joachim Protze

IT Center
Group: High Performance Computing
Division: Computational Science and Engineering
RWTH Aachen University
Seffenter Weg 23
D 52074 Aachen (Germany)
Tel: [phone]
Fax: [phone]
[email protected]
www.itc.rwth-aachen.de

[tgamblin]

I think that's more of a pain because we'd have to implement wrapper generation in Spack for everything installed as a script. I suppose I can imagine how to implement that, but it does change the way the package is installed. I worry that this would break assumptions for some packages, though. Imagine a package where the author wants to patch an installed script, but Spack replaces it with a wrapper. I suppose if spack does that only after all build tasks it would be ok, but I still think it might be hard to maintain...

[cyrush]

This bit us on chaos5 LLNL LC systems -- the kernel limit is actually 80 chars (after the shebang).

For our path we were getting cut off before the the hash even starts.

[tgamblin]

@cyrush: not sure the kernel limit is actually 80 chars, but that is what is printed out if this error happens. Want to test the fix I pushed? #497

[cyrush]

@tgamblin great timing -- we are meeting all day Tuesday to resolve build system issues. I will test this then.

[mathstuf]

I've seen shebangs being rewritten, so this should be fine now?

[tgamblin]

Yes. We've had a number of reports of this being fixed. Reopen if not.

[cyrush]

sorry for not reporting back -- we are successfully using the fix