Re: how execute a script
On Mon 16 Nov 2015 at 10:09:04 (+0100), tomas@tuxteam.de wrote:
> 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.
>
> [...]
You appear to be trying to shift the discussion to the semantics and
underlying implementation details of file extensions, and I don't know
why. I have clearly stated what I mean when I talk of "extension",
ie the same thing as what you called "ending" earlier.
These extensions/suffixes/endings, call them what you will, are
sufficiently useful to permeate the whole of the linux
filesystem. What I object to is being told that the reason I use
them is some sort of inheritance from DOS, and that to use them in
the names of scripts (scripts being singled out) is bad and not the
right thing.
I have explained why I use them, and how I mitigate any downside.
> > > 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.
Now you're trying to imply that there's some sort of scaling
problem. There isn't. These are scripts for my own use, written by
me. I use my naming convention to save my time and effort. I don't see
why I should be dictated to by someone like you who seems to think
that because the linux kernel ignores them, they shouldn't be there.
> > > 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.
You speak for yourself here. Perhaps you have some sort of history
with DOS. I checked back to see when having .xxx at the end of
filenames came into my own world. I used RT-11 indirectly in the
mid-1970s but TOPS-20 was probably the first direct use. You weren't
limited to 3 chars but IIRC the standard conventions were probably
inherited from earlier systems that were limited. I don't remember
being unhappy. The IBMs I used were limited to a service-inflicted
dww1.12345678.12345678(12345678) where PDS-files had the parenthesised
member names, so TOPS-20 was a huge relaxtion there. It also had
wildcards, completion and so on like a shell. I was happy.
> 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 :-)
Precisely. And I have my convention for my own scripts.
> [...]
>
> > > 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.
Precisely. I have described in what way it is useful to me.
> 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.
So you're trying to make me *not* have an extension just because the
kernel doesn't use it. Bully for the kernel. *I* use it. Back in the
1990s, I had several scripts which did much the same thing written in
perl and python, called foo.pl and foo.py, together with a foo link.
The link would point at .pl until I was happy testing .py, then I'd
move the link but keep .pl in my path in case I hit a snag. Judging
by my archive listings, that phase was over by mid-1998. Which
reminds me; how do you run "file foo" on a listing of file archives
to see what language foo is in?
> I hope I've made my point clear. You may want to follow or not.
You've made your point perfectly clear: you have a problem with other
people's filenames not following your convention. I don't.
I accept that there are plenty of poor choices to be made in filenames;
you mentioned NUL and whitespace above. But strict avoidance of
redundancy is not one of them IMO. Ambiguity, maybe. Contradiction
(calling a python script foo.sh) certainly.
> > 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?
I don't spend a lot of time worrying about my caches. I do think about
my fingers.
> (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
I'm really not interested in the timings, mine or yours. (Mine will
undoubtedly be worse.) What I'm concerned about is typing
find bin -type f -exec grep -l '^#!.*python' {} + | wc -l
versus
ls -1 bin/*py | wc -l
80
> (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?)
Well, that's hardly surprising in /usr/bin because they're part of the
system. I'm talking about my own collection of scripts, as was the OP,
I believe; what was it, a two-line script?
And before you look at "80" at start talking about farming links,
most of those are not callable scripts but just programs that I use
to do things. Because python is my preferred language for programs,
they could be described as scripts, but they're only ever invoked by
typing their name into xterm/VC.
What does "farming links" mean anyway? I've changed the implementation
language of one script (from sh to py) in the last five or so years,
moving one link. The oldest linked script I have is Oct 1998, though
obviously the date on the link is younger than the filesystem it sits
on. Adding -y to zip's commandline; does that count as farming?
Cheers,
David.
Reply to: