Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #160517 > unrolled thread

how execute a script

Back to article view | Back to linux.debian.user

Contents

  how execute a script Pol Hallen <deben@fuckaround.org> - 2015-11-13 15:00 +0100
    Re: how execute a script <tomas@tuxteam.de> - 2015-11-13 15:20 +0100
      Re: how execute a script Pol Hallen <deben@fuckaround.org> - 2015-11-13 15:50 +0100
        Re: how execute a script Lotek <lotek3@verizon.net> - 2015-11-14 01:30 +0100
        Re: how execute a script Pol Hallen <deben@fuckaround.org> - 2015-11-14 11:00 +0100
          Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-15 15:20 +0100
      Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-13 16:20 +0100
        Re: how execute a script Don Armstrong <don@debian.org> - 2015-11-13 18:20 +0100
          Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-13 22:20 +0100
            Re: how execute a script Don Armstrong <don@debian.org> - 2015-11-13 23:10 +0100
              Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-14 00:40 +0100
        Re: how execute a script <tomas@tuxteam.de> - 2015-11-14 08:40 +0100
          Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-16 05:50 +0100
            Re: how execute a script <tomas@tuxteam.de> - 2015-11-16 10:50 +0100
              Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-16 19:30 +0100
                Re: how execute a script <tomas@tuxteam.de> - 2015-11-17 09:20 +0100
    Re: how execute a script Gene Heskett <gheskett@shentel.net> - 2015-11-13 15:20 +0100
    Re: how execute a script Gene Heskett <gheskett@shentel.net> - 2015-11-13 15:30 +0100

#160517 — how execute a script

Hi all :-)

How can I execute a script inside a script?

I putted inside /home/user/.bashrc a line like this:

/home/user/bin/script1.sh

but the script does not run...

any idea?

thanks for help! :-)

Pol

[toc] | [next] | [standalone]

#160518

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, Nov 13, 2015 at 02:50:25PM +0100, Pol Hallen wrote:
> Hi all :-)
> 
> How can I execute a script inside a script?
> 
> I putted inside /home/user/.bashrc a line like this:
> 
> /home/user/bin/script1.sh
> 
> but the script does not run...
> 
> any idea?

Just saying the same as Darac is, but in a slightly different way:

Please post here

 (a) the result of the command "ls -l /home/user/bin/script1.sh"

and

 (b) the first couple of lines of this script

(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).

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZF6QsACgkQBcgs9XrR2kbi3QCfeZpSD1ZPxhymI1rvmM/E0wxa
p2wAn3RIpWh3SkUNJI6/FMXtYJnfHk/5
=5kxi
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#160521

>   (a) the result of the command "ls -l /home/user/bin/script1.sh"

-rwx------ 1 user000 user000  936 Dec  5  2014 script1.sh

my mistake sorry :-/

script1.sh checks (using apt-get update && apt-get upgrade) if there're 
(or not) any updates availables showing me only the total number of 
packages, so inside /home/user/.bashrc, exactly I've:

/home/user/bin/script1.sh &

the problem is "&" because without it script does run

after executing of script, output goes to shell with "| wall"

thanks

Pol

[toc] | [prev] | [next] | [standalone]

#160539

On 11/13/2015 06:43 AM, Pol Hallen wrote:
>>   (a) the result of the command "ls -l /home/user/bin/script1.sh"
>
> -rwx------ 1 user000 user000  936 Dec  5  2014 script1.sh
>
> my mistake sorry :-/
>
> script1.sh checks (using apt-get update && apt-get upgrade) if there're
> (or not) any updates availables showing me only the total number of
> packages, so inside /home/user/.bashrc, exactly I've:
>
> /home/user/bin/script1.sh &

Put the command at the end of ".profile".

It works for me.

    Lotek


>
> the problem is "&" because without it script does run
>
> after executing of script, output goes to shell with "| wall"
>
> thanks
>
> Pol
>
>

[toc] | [prev] | [next] | [standalone]

#160559

> Put the command at the end of /home/user/.profile
> It works for me.

thanks for help but does not work :-/

Pol

[toc] | [prev] | [next] | [standalone]

#160581

[Multipart message — attachments visible in raw view] — view raw

You can call a function from within a sourced file and it'll run (no matter
x bit).

So:

# ~/bin/runner.sh
runner () {
echo foo
}

runner

# ~/.bashrc
PATH="$PATH:~/bin"
source runner.sh
On Nov 14, 2015 4:51 AM, "Pol Hallen" <deben@fuckaround.org> wrote:

> Put the command at the end of /home/user/.profile
>> It works for me.
>>
>
> thanks for help but does not work :-/
>
> Pol
>
>

[toc] | [prev] | [next] | [standalone]

#160524

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*
-rwxr-xr-x 1 root root 1072 Apr 21  2014 /etc/init.d/checkroot-bootclean.sh*
-rwxr-xr-x 1 root root 9290 Apr 17  2014 /etc/init.d/checkroot.sh*
-rwxr-xr-x 1 root root 1423 Dec 31  2010 /etc/init.d/hostname.sh*
-rwxr-xr-x 1 root root 3916 Oct 15  2014 /etc/init.d/hwclock.sh*
-rwxr-xr-x 1 root root  677 Apr 21  2014 /etc/init.d/mountall-bootclean.sh*
-rwxr-xr-x 1 root root 2138 Apr 21  2014 /etc/init.d/mountall.sh*
-rwxr-xr-x 1 root root 1461 Apr 21  2014 /etc/init.d/mountdevsubfs.sh*
-rwxr-xr-x 1 root root 1564 Apr 21  2014 /etc/init.d/mountkernfs.sh*
-rwxr-xr-x 1 root root  685 Apr 21  2014 /etc/init.d/mountnfs-bootclean.sh*
-rwxr-xr-x 1 root root 2456 Apr 21  2014 /etc/init.d/mountnfs.sh*
-rwxr-xr-x 1 root root 2202 Apr 21  2014 /etc/init.d/umountnfs.sh*

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#160527

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.

When you run "ls bar"; you don't care if ls was written in perl, python,
C, bash, haskell, go, or fortran. 

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.

-- 
Don Armstrong                      http://www.donarmstrong.com

Information wants to be free to kill again.
 -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372

[toc] | [prev] | [next] | [standalone]

#160532

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.

[toc] | [prev] | [next] | [standalone]

#160533

On Fri, 13 Nov 2015, David Wright wrote:
> 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.

A good $EDITOR takes care of that for you. 

http://git.donarmstrong.com/?p=bin.git;a=tree is my own ~/bin; never had
any trouble figuring out what language things were... and if I needed
something to do it programmatically, file does a pretty good job itself.

> 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.

You've now got tab completion going to two different things, and twice
as many entries in ~/bin/ as you might expect. But hey; if it works for
you, great.

-- 
Don Armstrong                      http://www.donarmstrong.com

Q: What Can a Thoughtful Man Hope for Mankind on Earth, Given the
Experience of the Past Million Years?
A: Nothing.
 -- Bokonon _The Fourteenth Book of Bokonon_ (Vonnegut _Cats Cradle_)

[toc] | [prev] | [next] | [standalone]

#160536

On Fri 13 Nov 2015 at 16:08:07 (-0600), Don Armstrong wrote:
> On Fri, 13 Nov 2015, David Wright wrote:
> > 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.
> 
> A good $EDITOR takes care of that for you. 
> 
> http://git.donarmstrong.com/?p=bin.git;a=tree is my own ~/bin; never had
> any trouble figuring out what language things were... and if I needed
> something to do it programmatically, file does a pretty good job itself.

Well I find, say,   less bin/*py   much easier to type than
fiddling about with file or grep to get the same effect.

> > 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.
> 
> You've now got tab completion going to two different things, and twice
> as many entries in ~/bin/ as you might expect. But hey; if it works for
> you, great.

Tab completion just does the right thing: it matches up to the . and
then pressing return gets to follow the link.

And not twice as many. The only links are to the scripts that get
called from elsewhere. There aren't that many. As I've said, these
are personal scripts so there's no need for it to scale up like the
system.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#160552

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> 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.

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.

The one case where an "extension" (as you call it: DOS, see?) might
make sense (I'd say a hint in the filename) is when your script isn't
an executable in itself but a collection of functions you *source*
from another shell: this so-called "shell library" has to be shell
code (i.e. you can't change implementation).

And snobbery? Pthttht.

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZG3AQACgkQBcgs9XrR2kb2XQCeMEBnjZw0/6L2zImjZ27pgHlI
MfoAn0dyW5n4u5XZdXzlR8XpR6DPaupL
=pM11
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#160608

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), going back to the origins of unix and further.

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.

> > 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.
> 
> 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."

> 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").'

> might
> make sense (I'd say a hint in the filename) is when your script isn't
> an executable in itself but a collection of functions you *source*
> from another shell: this so-called "shell library" has to be shell
> code (i.e. you can't change implementation).

Well, yes, that's frequently recommended in such cases.

> 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).

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.

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.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#160625

-----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-----

[toc] | [prev] | [next] | [standalone]

#160635

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.

[toc] | [prev] | [next] | [standalone]

#160660

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, Nov 16, 2015 at 12:29:00PM -0600, David Wright wrote:

[...]

> > 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.

At this point, I think our discussion is reaching the point of diminishing
returns (definitely for me, but I think for you also) -- so let's agree
to differ.

You do whatever you want on your box. For me, *having to* have an ending
for a file is definitely a "design smell" (the authors of the Debian
policy, btw, agree with me on that [1]).

I'm out of this discussion.

[1] <https://www.debian.org/doc/debian-policy/ch-files.html#s-scripts>

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlZK2bYACgkQBcgs9XrR2kZbtQCfTlZkLEeD515dDuuw+1FNLFl6
PAQAn1av0QiYYnohErqiA0YXRiAJ9T2s
=L/0R
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#160519

On Friday 13 November 2015 08:50:25 Pol Hallen wrote:

> Hi all :-)
>
> How can I execute a script inside a script?
>
> I putted inside /home/user/.bashrc a line like this:
>
> /home/user/bin/script1.sh
>
> but the script does not run...
>
> any idea?
>
chmod +x?

> thanks for help! :-)
>
> Pol


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#160520

On Friday 13 November 2015 08:50:25 Pol Hallen wrote:

> Hi all :-)
>
> How can I execute a script inside a script?
>
> I putted inside /home/user/.bashrc a line like this:
>
> /home/user/bin/script1.sh
>
> but the script does not run...
>
> any idea?
>
Actually chmod +x script1.sh

> thanks for help! :-)
>
> Pol


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web