New: execve(2) manual page ".sh" usage exposes implementation detail
https://bugzilla.kernel.org/show_bug.cgi?id=84701
Bug ID: 84701
Summary: execve(2) manual page ".sh" usage exposes
implementation detail
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: man-pages
Assignee: documentation_man-pages-ztI5WcYan/[email protected]
Reporter: [email protected]
Regression: No
This content:
We can also use these programs to demonstrate the use of a script
interpreter. To do this we create a script whose "interpreter" is our
myecho program:
$ cat > script.sh
#! ./myecho script-arg
^D
$ chmod +x script.sh
We can then use our program to exec the script:
$ ./execve ./script.sh
argv[0]: ./myecho
argv[1]: script-arg
argv[2]: ./script.sh
argv[3]: hello
argv[4]: worldShould probably instead read:
We can also use these programs to demonstrate the use of a script
interpreter. To do this we create a script whose "interpreter" is our
myecho program:
$ cat > script
#!./myecho script-arg
^D
$ chmod +x script
We can then use our program to exec the script:
$ ./execve ./script
argv[0]: ./myecho
argv[1]: script-arg
argv[2]: ./script
argv[3]: hello
argv[4]: worldRationale:
1) Command name extensions considered harmful: Adding ".sh", or any other unneeded extension, unnecessarily duplicates meta information already present in the interpreter directive, exposing an implementation detail that then ends up explicitly part of other programs running this one. Later, when such a script is replaced with a new version in Python, C, etc., the useless ".sh" has to be retained to avoid breaking those other programs' calls to this one, and now has a stark antifunction of lying about the script's content and occasionally causing admins to run undefined experiments as root (like "bash -x ./reallyperlscript.sh"). Such extensions, while fine in DOS which ignores extensions explicitly, is a serious flaw in Unix-targeted script writing. Canonical documentation from the Linux manual should not support such a flawed idiom - recommending against it would be preferred.
A more extensive rant against them can be found at:
http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful
2) The space after "#!" in the interpreter directive is minor - and the kernel's fs/binfmt_script.c specifically allows for it - but versions of unix have length limits from ~30 characters to linux's 127 or so (if that number's correct) so the space does have a cost. Most scripts I've seen lack that space, and there's no real reason to encourage it.
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 84701] execve(2) manual page ".sh" usage exposes implementation detail
In reply to a message not in the archivehttps://bugzilla.kernel.org/show_bug.cgi?id=84701
Michael Kerrisk <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |[email protected]
Resolution|--- |CODE_FIX--- Comment #1 from Michael Kerrisk <[email protected]> --- Alex, thanks for the detailed report. I've applied the patch below.
Cheers,
Michael
man2/execve.2 +5 -5
@@ -729,10 +729,10 @@ program: .in +4n .nf -.RB "$" " cat > script.sh" -.B #! ./myecho script-arg +.RB "$" " cat > script" +.B #!./myecho script-arg .B ^D -.RB "$" " chmod +x script.sh" +.RB "$" " chmod +x script" .fi .in
@@ -740,10 +740,10 @@ We can then use our program to exec the script: .in +4n .nf -.RB "$" " ./execve ./script.sh" +.RB "$" " ./execve ./script" argv[0]: ./myecho argv[1]: script-arg -argv[2]: ./script.sh +argv[2]: ./script argv[3]: hello argv[4]: world .fi
Signature · 6 lines
You are receiving this mail because: You are watching the assignee of the bug. -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html