Re: how execute a script
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sun, Nov 15, 2015 at 10:47:13PM -0600, David Wright wrote:
> On Sat 14 Nov 2015 at 08:00:20 (+0100), tomas@tuxteam.de wrote:
> > On Fri, Nov 13, 2015 at 09:11:34AM -0600, David Wright wrote:
> > > On Fri 13 Nov 2015 at 14:43:39 (+0100), tomas@tuxteam.de wrote:
> > >
> > > > (as an aside: it's bad custom inherited from DOS to name shell scripts
> > > > with an .sh ending. No ending is the right thing here).
> > >
> > > So these were all DOS scripts once, were they?
> > >
> > > -rwxr-xr-x 1 root root 1248 Apr 21 2014 /etc/init.d/bootmisc.sh*
> > > -rwxr-xr-x 1 root root 3807 Apr 21 2014 /etc/init.d/checkfs.sh*
> >
> > [...]
> >
> > Very smart. I didn't say the scripts are inherited from DOS. That bad
> > habit is, definitely.
>
> Well file extensions in general are of course much older than DOS
> (assuming you mean MSDOS-compatible rather than the old meaning as in,
> say, DOS/360 etc),
I guess that comes from CP/M, DOS being a cheap ripoff therefrom. But
that's more or less the horizon of my memories.
> going back to the origins of unix and further.
Unix? File Extensions? -- Citation needed.
> As for script-file extensions in DOS, there was really only .BAT
> wasn't there?, so the idea of distinguishing .bash, .csh, .py, .pl,
> .sh, .zsh etc as being inherited from DOS is difficult for me to
> understand. I have no idea what was going through the head of whoever
> christened /etc/init.d/hostname.sh originally.
The point is -- DOS had (remember 8+3) a special place for the "extension"
in the file system data structures. The OS kernel special-cased a whole
bunch of those extensions (.SYS, .COM, .EXE, .BAT) comes to mind. You
couldn't put two dots in a file name. Later, layers and layers of crust
piled on top of that. Windows hides the "extension" (I still receive
mails with attachments called foo.jpg.exe, a far echo of this unholy
mess of special cases on top of special cases).
Whereas in UNIX, a file name is just a string: very few characters are
special: steer clear of NUL and slash. If you want to have an easy life
with shell scripts, steer clear of whitespace.
[...]
> > No. If you call your scripts from other places, and -- say -- change
> > the implementation from shell to ruby: do you have to run around and
> > fix all the call sites? Have fun.
>
> Of course I don't. Just write a foo.rb script, and when happy with it,
> move the link to point at it. Above, you just quoted my saying
> "Extensionless filenames are either links or binaries."
So you have a link farm for every bunch of executables? Happy farming.
> > The one case where an "extension" (as you call it: DOS, see?)
>
> "Extension" is a generally understood shorthand that's been around for
> years. Should we go through man pages such as gzip and change the word
> to "suffix"? Or we could go back to using the language of dmr, as in:
> 'Arguments whose names end with ".c" are assumed to be C source
> programs; they are compiled, and the object program is left on the
> file sfile.o (i.e. the file whose name is that of the source with ".o"
> substituted for ".c").'
I have no problems with the moniker "extension" -- although it comes
from unhappy times. I have no problems with the convention to end
C source files with ".c" and objects with ".o" (after all, this makes
writing makefiles easier!). But look at the ugly things Windows
folks do ("Makefile.mak", horrors!) just because, with their slavish
DOS roots, every file gotta have an extension).
Conventions are good, slavery is bad. Or some such :-)
[...]
> > And snobbery? Pthttht.
>
> Well, I'm just trying to find a motive for your condemnation, the use
> of words like "right thing" and "bad", and your conviction that it's
> all down to DOS (not just the phenomenon but even the word I used to
> describe it).
Well -- I think I tried to describe it above. Let me put it more
abstractly: the file name pattern (of which the ending is but one
part!) follows some conventions because it's useful. The driver
of such conventions will typically be the *intended use* of the file
and not the *contents*.
So an executable (a "command", the things that typically end up
in /usr/bin or in ~/bin) should "look the same" regardless of
whether it's written in Forth or Lisp. Which "interpreter" to
fire up (ld.so, /bin/bash, /usr/bin/tclsh) is something the binfmt
or the "#!" is for. *That* is what an Unix kernel looks at (whereas
a DOS kernel looked at the ".SYS", ".COM", etc.
I hope I've made my point clear. You may want to follow or not.
> I've never distributed a library, but have read about distributions
> being packaged with file extensions, these then being stripped off at
> installation time. As already explained in this thread, I achieve
> the same effect with a link. I don't have enough scripts to have a
> separate archive all packaged up and with an installation script, but
> I want to be able to see the various scripting languages without
> having to open the files themselves.
Sounds a bit like Rube Goldberg to me. Transporting the pattern of
"compile stuff" to a case where you don't need it. Not for me.
> Say I want to see how many python scripts are still using a module
> that I'm eliminating. I type grep ... ~/bin/*py just as I would if
> python was a compiled language, rather than testing every file in
> ~/bin/* with file to discover its source language.
If it's python scripts, I'd prepend a "grep '#!.*python". Might take
a tad longer. When your caches are cold. So what?
(An example: my box is CPU starved and doing full disk encryption.
The method is hackish -- test every line for the hashbang cookie
instead of just the first, yadda):
tomas@rasputin:~$ sudo bash -c "echo 1 > /proc/sys/vm/drop_caches"
tomas@rasputin:~$ time find /usr/bin -type f -exec grep -l '^#!.*python' {} + | wc -l
36
real 0m29.282s
user 0m0.676s
sys 0m1.224s
tomas@rasputin:~$ time find /usr/bin -type f -exec grep -l '^#!.*python' {} + | wc -l
36
real 0m0.570s
user 0m0.296s
sys 0m0.264s
tomas@rasputin:~$ sudo bash -c "echo 1 > /proc/sys/vm/drop_caches"
tomas@rasputin:~$ time find /usr/bin -type f -name "*.py" | wc -l
0
real 0m0.225s
user 0m0.024s
sys 0m0.004s
tomas@rasputin:~$ time find /usr/bin -type f -name "*.py" | wc -l
0
real 0m0.017s
user 0m0.008s
sys 0m0.008s
(BTW: none of those 36 python scripts in /usr/bin have the .py ending:
note the zero in the second case? Perhaps there's method to this?)
regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iEYEARECAAYFAlZJnTAACgkQBcgs9XrR2kYv8gCggS5eZCqSvB39ilGLElIE/d5h
Rm4An1V8jUUoHWmUYFhywid2X7L0RmcO
=A87z
-----END PGP SIGNATURE-----
Reply to: