Re: how execute a script
On Fri 13 Nov 2015 at 11:18:17 (-0600), Don Armstrong wrote:
> On Fri, 13 Nov 2015, David Wright wrote:
> > I name my scripts in ~/bin with an extension corresponding to their
> > contents: .pl .py .sh etc. Where I'm working on alternative versions,
> > I might have more than one language. Extensionless filenames are
> > either links or binaries. What's bad about this? Or is it just
> > snobbery: Look, we don't need extensions.
>
> The reason why it's bad is because you're encoding a mostly irrelevant
> implementation detail in the interface to your program.
No—that's what the links are for, and why they're extensionless.
They're the scripts that are well-defined and often called from a
variety of places.
The implementation isn't necessarily irrelevant when you have to
maintain the scripts yourself. Just at the level of pressing F3 in mc,
or running less, it saves time knowing what you expect to appear on
the screen.
> When you run "ls bar"; you don't care if ls was written in perl, python,
> C, bash, haskell, go, or fortran.
I also don't care that /usr/sbin/logwatch → /usr/share/logwatch/scripts/logwatch.pl
> Things that live outside of PATH sometimes violate this practice. Often
> in cases where the interface is constrained or the actual implementation
> language is not an irrelevant detail.
Well I do have a few scripts that are off-PATH, mainly helpers for
.bashrc, .xsession etc named .bash-foo... which sit in my home directory
(collating next to the files they help). But I don't have enough
scripts to feel the need for a distinct off-PATH archive directory
structure. Things are different for the system, where one has links like
/usr/bin/hp-print → /usr/share/hplip/print.py
/usr/bin/pdfcrop → /usr/share/texlive/texmf-dist/scripts/pdfcrop/pdfcrop.pl
each of which is just the tip of an iceberg.
I have links and scripts such as
radio2wav → record2wav.py stoprecording → stoprecording.sh
vinyl2wav → record2wav.py
which are used both directly and by cron, but also scripts like
split-tracks.py which would only ever be used from the command line.
All these reside together in my ~/bin/ which is on-PATH.
Cheers,
David.
Reply to: