Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Nov 18, 2015 at 08:54:46AM -0600, David Wright wrote:
> On Wed 18 Nov 2015 at 08:47:59 (+0100), to...@tuxteam.de wrote:
> 
> > Here, gunzip is seeing the file name. Since gzip, by convention, removes
> > the original (and gunzip the compressed), effectively replacing each by
> > the other), those programs are extra careful. The file name pattern is
> > part of the interface specification.
> 
> [...]
> 
> > And that makes sense. In a way yes, it has two personalities: an
> > "in-place" (de) compressor and a filter. The first one enforces a
> > file pattern convention because it's (potentially) deleting stuff.
> > 
> > Not that I personally like the in-place thing, mind you. I guess
> > it was born out of necessity: if you are zipping a file which is
> > much bigger than what you've space left on device, this interface
> > makes sense.
> 
> What you appear to be saying here is that the new version overwrites
> the head of the file while the program is still reading the tail.
> This doesn't happen: a new file is written and, when complete, the
> old file is removed. So there's always a period when both compressed
> and uncompressed versions exist simultaneously on the filesystem.

What I was saying was that the interface *allows it*. Whether it's
implemented this way is another question, but... watch this space.

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

iEYEARECAAYFAlZMjmQACgkQBcgs9XrR2kaaWwCfcGB2Ab4/eQnGWaqDl32xezkX
41sAn3z3/uQVzBsBX0EhzINKm7hnh2Ws
=kCA8
-END PGP SIGNATURE-

Re: how execute a script

[David Wright]

On Wed 18 Nov 2015 at 15:42:44 (+0100), to...@tuxteam.de wrote:
> On Wed, Nov 18, 2015 at 08:54:46AM -0600, David Wright wrote:
> > On Wed 18 Nov 2015 at 08:47:59 (+0100), to...@tuxteam.de wrote:
> > 
> > > Here, gunzip is seeing the file name. Since gzip, by convention, removes
> > > the original (and gunzip the compressed), effectively replacing each by
> > > the other), those programs are extra careful. The file name pattern is
> > > part of the interface specification.
> > 
> > [...]
> > 
> > > And that makes sense. In a way yes, it has two personalities: an
> > > "in-place" (de) compressor and a filter. The first one enforces a
> > > file pattern convention because it's (potentially) deleting stuff.
> > > 
> > > Not that I personally like the in-place thing, mind you. I guess
> > > it was born out of necessity: if you are zipping a file which is
> > > much bigger than what you've space left on device, this interface
> > > makes sense.
> > 
> > What you appear to be saying here is that the new version overwrites
> > the head of the file while the program is still reading the tail.
> > This doesn't happen: a new file is written and, when complete, the
> > old file is removed. So there's always a period when both compressed
> > and uncompressed versions exist simultaneously on the filesystem.
> 
> What I was saying was that the interface *allows it*. Whether it's
> implemented this way is another question, but... watch this space.

Sorry. I thought this thread was discussing Brian's *concrete*.

Cheers,
David.

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 05:17:46PM -0500, shawn wilson wrote:

[...]

> > Got it. But magic *can* do many of those things. A headless shell
> > script is a tough nut to crack, though: "echo" could occur as well
> > in a Tcl script (via Tcl's crazy but genius "unknown" mechanism).
> >
> 
> You're right - just "script" then. I'm not dissing magic - it's a good
> starting point in forensics or to see what's in a bin directory, but
> shouldn't be relied on (also see ftimes xmagic for a more featureful
> magic implementation w/e sf comes back up).
> 
> My point is that you can't determine what you're looking at w/o being
> told (an extension)

Here we agree (up to your parens): the shebang[1] is just another way
of being told (just sticking a shebang in front of a file doesn't
guarantee that the invoked interpreter will be able to make heads or
tails of it). So in both cases it's just metadata (which always can
lie). What I'm trying to say is that stuffing the metadata in the file
itself is more robust than stuffing it in the file name (which never
was designed for that, at least not in Unix).

Current usage and conventions is a mixture of both.

> or looking at it. So (my original point) you loose
> data by removing/not having an extension.

still: less metadata into the file name and more into the file itself
reduces long-term pain.

[1] Or the 0x7F 'ELF', or the 0xFF 0xD8  'JFIF' or whatever
   at the start of a file. All of 'em stating: "this os a JPEG, promised".
   If you really want to find out whether something is really a C file,
   you'd have to throw the C compiler at it. You find yourself quickly
   wrangling with Turing completeness, i.e. with decidability :-)

   And what's this (yes, I meet such things at $WORK):

   #!/bin/sh
   # Dont touch first 3 lines of this file \
   : ${TCL_DEBUG="-n"}; exec TclSh ${TCL_DEBUG:+"$TCL_DEBUG"} "$0" ${1+"$@"}

   Yes, a Polyglot. It's Tcl and shell. So... all metadata. In the file name
   or in the file itself.

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

iEYEARECAAYFAlZMKW8ACgkQBcgs9XrR2kbmwwCeNQJxfRkO4UoaEW6a5W5aC78Q
GisAn0yROlZTbWdyLn+T7EsG6i7CSHfs
=1B0u
-END PGP SIGNATURE-

Re: how execute a script

[Brian]

On Wed 18 Nov 2015 at 08:49:13 +0100, to...@tuxteam.de wrote:

> On Tue, Nov 17, 2015 at 11:08:24PM +, Brian wrote:
> > On Tue 17 Nov 2015 at 21:18:57 +0100, to...@tuxteam.de wrote:
> > 
> > > On Tue, Nov 17, 2015 at 06:56:40PM +, Brian wrote:
> > > 
> > > [...]
> > > 
> > > > My example: gv does not recognise the PDF file 'test' as something it is
> > > > *capable of opening*. With 'test' as the only file in a directory the
> > > > command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
> > > > opens the file, which is all that matters.
> > > 
> > > The TAB thing is your shell's autocompletion talking, gv isn't involved.
> > > And yes, shell's autocompletion usually relies on the file name pattern
> > > (dot-ending, aka "extension" is but a special case of that).
> > 
> > David Wright said something similar.
> > 
> >   https://lists.debian.org/debian-user/2015/11/msg00631.html
> > 
> > The file "example" is a PDF.
> > 
> > 'gs exa' and 'mupdf exa' TAB complete the file name. gv and xpdf do
> > not. Is the shell being discriminatory?
> 
> Just your shell's autocompletion patterns. Fix them if you don't like
> them :-)

To be precise, the bash-completion package causes this behaviour. gv
and xpdf have lines in /usr/share/bash-completion/bash_completion; mupdf
and gs do not.

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 11:08:24PM +, Brian wrote:
> On Tue 17 Nov 2015 at 21:18:57 +0100, to...@tuxteam.de wrote:
> 
> > On Tue, Nov 17, 2015 at 06:56:40PM +, Brian wrote:
> > 
> > [...]
> > 
> > > My example: gv does not recognise the PDF file 'test' as something it is
> > > *capable of opening*. With 'test' as the only file in a directory the
> > > command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
> > > opens the file, which is all that matters.
> > 
> > The TAB thing is your shell's autocompletion talking, gv isn't involved.
> > And yes, shell's autocompletion usually relies on the file name pattern
> > (dot-ending, aka "extension" is but a special case of that).
> 
> David Wright said something similar.
> 
>   https://lists.debian.org/debian-user/2015/11/msg00631.html
> 
> The file "example" is a PDF.
> 
> 'gs exa' and 'mupdf exa' TAB complete the file name. gv and xpdf do
> not. Is the shell being discriminatory?

Just your shell's autocompletion patterns. Fix them if you don't like
them :-)

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

iEYEARECAAYFAlZMLXkACgkQBcgs9XrR2kb3vQCeOPw8K+AOlTAW6yIBdkC7YUx8
YT8An38r5nofXXWWSobQ8rRSpjTVRk0w
=yVkS
-END PGP SIGNATURE-

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 11:08:46PM +, Brian wrote:
> On Tue 17 Nov 2015 at 21:41:01 +0100, Luis Felipe Tabera Alonso wrote:
> 
> > On Tuesday 17 November 2015 20:21:23 Brian wrote:
> > > 
> > > I've also asked for a *concrete example* of a program not opening a file
> > > because of the lack of an extension. It hasn't yet been given.
> > 
> > $ gunzip file 
> > gzip: file: unknown suffix -- ignored

Here, gunzip is seeing the file name. Since gzip, by convention, removes
the original (and gunzip the compressed), effectively replacing each by
the other), those programs are extra careful. The file name pattern is
part of the interface specification.

> That is a good example.
> 
>   brian@desktop:~$ cp /etc/services test
>   brian@desktop:~$ file test
>   test: ASCII text
> 
>   brian@desktop:~$ gzip test
> 
>   brian@desktop:~$ file test.gz 
>   test.gz: gzip compressed data, was "test", last modified: Tue Nov 17 
> 21:49:33 2015, from Unix
> 
>   brian@desktop:~$ mv test.gz test-1
> 
> test-1 has no extension. Does gzip have two personalities? :)
> 
>   brian@desktop:~$ gunzip < test-1 > test-2

Here, gunzip works as a filter. It doesn't even *see* the file name,
the shell opens the file for it (because of the <) and feeds its
content via gunzip's stdin.

Same case as upthread with tab completion. It's very important to
think carefully what the program "sees" and what the shell is doing
for it.

>   brian@desktop:~$ file test-2 
>   test-2: ASCII text
> 
> Interesting. gunzip will decompress a file without an extension. Does it
> have two personalities? :)
> 
> Alternatively:
> 
>   zcat test-1 > test-2 

Zcat, zless and co behave like cat & less with a prepended unzip filter.

> > $mv file other.gz
> > $gunzip other.gz 
> > $ls
> > other
> 
>   $mv file other.
>   $gunzip -S . other.
>   $ls
>   other
> 
> gunzip is a tool that does seem to care what the files are named.

And that makes sense. In a way yes, it has two personalities: an
"in-place" (de) compressor and a filter. The first one enforces a
file pattern convention because it's (potentially) deleting stuff.

Not that I personally like the in-place thing, mind you. I guess
it was born out of necessity: if you are zipping a file which is
much bigger than what you've space left on device, this interface
makes sense.

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

iEYEARECAAYFAlZMLS8ACgkQBcgs9XrR2kaxzgCeLEa3vyEZYoKvPdNkJ+k7rSDl
hTsAn0dsH9+ygZsvk4wgzGdQQ8fXgX4r
=Q/Iq
-END PGP SIGNATURE-

Re: how execute a script

[David Wright]

On Wed 18 Nov 2015 at 08:47:59 (+0100), to...@tuxteam.de wrote:

> Here, gunzip is seeing the file name. Since gzip, by convention, removes
> the original (and gunzip the compressed), effectively replacing each by
> the other), those programs are extra careful. The file name pattern is
> part of the interface specification.

[...]

> And that makes sense. In a way yes, it has two personalities: an
> "in-place" (de) compressor and a filter. The first one enforces a
> file pattern convention because it's (potentially) deleting stuff.
> 
> Not that I personally like the in-place thing, mind you. I guess
> it was born out of necessity: if you are zipping a file which is
> much bigger than what you've space left on device, this interface
> makes sense.

What you appear to be saying here is that the new version overwrites
the head of the file while the program is still reading the tail.
This doesn't happen: a new file is written and, when complete, the
old file is removed. So there's always a period when both compressed
and uncompressed versions exist simultaneously on the filesystem.

Cheers,
David.

Re: how execute a script

[shawn wilson]

On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
>
> On Monday 16 November 2015 19:33:51 David Wright wrote:
> > On Mon 16 Nov 2015 at 06:54:40 (+0100), Martin Str|mberg wrote:
> > > In article  David Wright
>  wrote:
> > > > 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.
> > >
> > > Perhaps it's because (MS)DOS begat WINDOWS that only knew how to run
> > > something based on the extension?
> > >
> > > And that is why we shudder on the sight of a (unnecessary?) extension?
> >
> > I wouldn't know. My experience of windows is far less than DOS, and my
> > use of DOS was pretty much restricted to an AUTOEXEC.BAT that started
> > an emulation system which was my area of expertise. Interesting choice
> > of language, though; shudder.
> >
> > I'm the person questioning the relevance of DOS to putting ".sh" at
> > the end of an on-PATH executable script's filename, when DOS was
> > brought up in https://lists.debian.org/debian-user/2015/11/msg00453.html
> >
> > I take it there's a whole generation of folk who gained their
> > experience of filename endings (a less loaded word than extension)
> > through DOS/windows, perhaps entirely so. With it, they picked up a
> > load of negative associations, causing shuddering here and unhappiness
> > in another part of this thread.
> >
> > I'm sorry for you. I didn't touch DOS until 1992-06-01 (to be precise)
> > about twentyone years into my computing career. To say I *used* it
> > would be an overstatement: I ran one package on it.
> >
> > Putting meaningful endings onto filenames (excepting, I hasten to
> > add lest people jump down my throat, executable scripts) had been a
> > way of life for years. Their necessity was variable from system to
> > system; sometimes they were just a convention. Look at   man gcc.
> > It has meaningful endings. They've been there since at least
> > 15 March 1972 when, allegedly, the number of Unix installations had
> > grown to 10. (At that time, gcc was obviously called cc; Stallman
> > hadn't yet graduated.)
> >
> > As for unix scripts, well, yes, there's no *need* for any endings,
> > but that doesn't preclude their use. If that makes you unhappy or
> > into a shudderer, please get over it.
>
> I take it those who are so against file endings are equally upset by
> sources.list and menu.lst?
>
> Though it is very annoying when they are *needed*.  Xsane usually puts
them
> in, and I used not to bother to check.  A few months ago I sent my lawyer
a
> scan of a document he needed.  An hour or two later, back came an
> email:  "I'm so sorry, we have no software that can open that file.  The
IT
> department has been trying for an hour".  Puzzled, because I thought I had
> sent a .pdf, and had checked that it opened fine in Evince, I looked at
the
> file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
opened
> fine.
>

Magic shouldn't be used when a file type is known and should be
communicated (via its extension). If you create a pdf, it is bad to not
have the pdf extension - you've lost data.

Also, I'm fine with installed executables not including extensions.
However, in a repo with different types of executable code, I want to know
at a glance what something is (there's also that vim filetype uses
extension and I want stuff to work).

Re: how execute a script

[Elimar Riesebieter]

* shawn wilson  [2015-11-17 13:08 -0500]:

> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>  wrote:
> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:

[...]

> >> communicated (via its extension). If you create a pdf, it is bad to not
> >> have the pdf extension - you've lost data.
> >
> > How have you lost data?
> >
> 
> You loose what the file type (data) should be if you save a file w/o
> an extension. Again, this is fine for an installed program (no one
> cares as long as it works) but not so good for data that is processed
> by another program or a script I want to edit.

PDF files are recognized by their header not their extension. Create
a test.pdf. Copy it to test and test.blo. They will always be
recognized as pdf documents from evince and alike.

Elimar
-- 
 >what IMHO then?
  IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
  --posting from alex in debian-user--

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Nov 18, 2015 at 07:02:01AM +1300, Chris Bannister wrote:
> On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> > On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> > > department has been trying for an hour".  Puzzled, because I thought I had
> > > sent a .pdf, and had checked that it opened fine in Evince, I looked at
> > the
> > > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
> > 
> > communicated (via its extension). If you create a pdf, it is bad to not
> > have the pdf extension - you've lost data.
> 
> How have you lost data? 

I understood shawn as meaning the metadata hidden in the file name (as in
"this is a PDF file").

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

iEYEARECAAYFAlZLZToACgkQBcgs9XrR2kaHkgCdGjzs1RYJrrzx83YxCtz37C65
2zIAnjHpCmUh8OITv7/jH5i1F+sgW4Sv
=ZXmH
-END PGP SIGNATURE-

Re: how execute a script

[Chris Bannister]

On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> > department has been trying for an hour".  Puzzled, because I thought I had
> > sent a .pdf, and had checked that it opened fine in Evince, I looked at
> the
> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
> 
> communicated (via its extension). If you create a pdf, it is bad to not
> have the pdf extension - you've lost data.

How have you lost data? 

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
 wrote:
> On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
>> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
>> > department has been trying for an hour".  Puzzled, because I thought I had
>> > sent a .pdf, and had checked that it opened fine in Evince, I looked at
>> the
>> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
>>
>> communicated (via its extension). If you create a pdf, it is bad to not
>> have the pdf extension - you've lost data.
>
> How have you lost data?
>

You loose what the file type (data) should be if you save a file w/o
an extension. Again, this is fine for an installed program (no one
cares as long as it works) but not so good for data that is processed
by another program or a script I want to edit.

Re: how execute a script

[Brian]

On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:

> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>  wrote:
> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> >> > department has been trying for an hour".  Puzzled, because I thought I 
> >> > had
> >> > sent a .pdf, and had checked that it opened fine in Evince, I looked at
> >> the
> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
> >>
> >> communicated (via its extension). If you create a pdf, it is bad to not
> >> have the pdf extension - you've lost data.
> >
> > How have you lost data?
> 
> You loose what the file type (data) should be if you save a file w/o
> an extension. Again, this is fine for an installed program (no one
> cares as long as it works) but not so good for data that is processed
> by another program or a script I want to edit.

You would have to give a specific example where a file processed by a
program or script fails to open for this argument to be convincing, You
also have to distinguish between data in the file and information the
extension conveys to the program.

My example: gv does not recognise the PDF file 'test' as something it is
*capable of opening*. With 'test' as the only file in a directory the
command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
opens the file, which is all that matters.

Your example is?

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 1:25 PM, Elimar Riesebieter  wrote:
> * shawn wilson  [2015-11-17 13:08 -0500]:
>
>> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>>  wrote:
>> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
>
> [...]
>
>> >> communicated (via its extension). If you create a pdf, it is bad to not
>> >> have the pdf extension - you've lost data.
>> >
>> > How have you lost data?
>> >
>>
>> You loose what the file type (data) should be if you save a file w/o
>> an extension. Again, this is fine for an installed program (no one
>> cares as long as it works) but not so good for data that is processed
>> by another program or a script I want to edit.
>
> PDF files are recognized by their header not their extension. Create
> a test.pdf. Copy it to test and test.blo. They will always be
> recognized as pdf documents from evince and alike.
>

Quoting myself (sorry):
> Magic shouldn't be used when a file type is known

Re: how execute a script

[Brian]

On Tue 17 Nov 2015 at 21:18:57 +0100, to...@tuxteam.de wrote:

> On Tue, Nov 17, 2015 at 06:56:40PM +, Brian wrote:
> 
> [...]
> 
> > My example: gv does not recognise the PDF file 'test' as something it is
> > *capable of opening*. With 'test' as the only file in a directory the
> > command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
> > opens the file, which is all that matters.
> 
> The TAB thing is your shell's autocompletion talking, gv isn't involved.
> And yes, shell's autocompletion usually relies on the file name pattern
> (dot-ending, aka "extension" is but a special case of that).

David Wright said something similar.

  https://lists.debian.org/debian-user/2015/11/msg00631.html

The file "example" is a PDF.

'gs exa' and 'mupdf exa' TAB complete the file name. gv and xpdf do
not. Is the shell being discriminatory?

Re: how execute a script

[Brian]

On Tue 17 Nov 2015 at 21:41:01 +0100, Luis Felipe Tabera Alonso wrote:

> On Tuesday 17 November 2015 20:21:23 Brian wrote:
> > 
> > I've also asked for a *concrete example* of a program not opening a file
> > because of the lack of an extension. It hasn't yet been given.
> 
> $ gunzip file 
> gzip: file: unknown suffix -- ignored

That is a good example.

  brian@desktop:~$ cp /etc/services test
  brian@desktop:~$ file test
  test: ASCII text

  brian@desktop:~$ gzip test

  brian@desktop:~$ file test.gz 
  test.gz: gzip compressed data, was "test", last modified: Tue Nov 17 21:49:33 
2015, from Unix

  brian@desktop:~$ mv test.gz test-1

test-1 has no extension. Does gzip have two personalities? :)

  brian@desktop:~$ gunzip < test-1 > test-2

  brian@desktop:~$ file test-2 
  test-2: ASCII text

Interesting. gunzip will decompress a file without an extension. Does it
have two personalities? :)

Alternatively:

  zcat test-1 > test-2 

> $mv file other.gz
> $gunzip other.gz 
> $ls
> other

  $mv file other.
  $gunzip -S . other.
  $ls
  other

gunzip is a tool that does seem to care what the files are named.

Re: how execute a script

[Don Armstrong]

On Tue, 17 Nov 2015, Brian wrote:
>   $mv file other.
>   $gunzip -S . other.
>   $ls
>   other
> 
> gunzip is a tool that does seem to care what the files are named.

See the --no-name/--name option.

By default the name and timestamp of the uncompressed file is saved when
the file is compressed so that it can be restored when it is
uncompressed.

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

That's the wonderful thing about crayons. They can take you to more
places than a starship.
 -- Guinan "Star Trek: The Next Generation: Rascals (#6.7)"

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 1:56 PM, Brian  wrote:
> On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
>
>> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>>  wrote:
>> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
>> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
>> >> > department has been trying for an hour".  Puzzled, because I thought I 
>> >> > had
>> >> > sent a .pdf, and had checked that it opened fine in Evince, I looked at
>> >> the
>> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
>> >>
>> >> communicated (via its extension). If you create a pdf, it is bad to not
>> >> have the pdf extension - you've lost data.
>> >
>> > How have you lost data?
>>
>> You loose what the file type (data) should be if you save a file w/o
>> an extension. Again, this is fine for an installed program (no one
>> cares as long as it works) but not so good for data that is processed
>> by another program or a script I want to edit.
>
> You would have to give a specific example where a file processed by a
> program or script fails to open for this argument to be convincing, You
> also have to distinguish between data in the file and information the
> extension conveys to the program.
>

How about just that vim filetype relies on the filename to determine the format?

I suspect there are other examples where an extension might be
*required* such as compression, but other than Windows, IDK off hand.

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 03:15:21PM -0500, shawn wilson wrote:
> >  % file t.sh
> > t.sh: ASCII text
> >  % cat t.sh
> > max=10
> >
> 
> Oh and before someone says "but there's some standard that says you're
> supposed to put a shebang at the top" - afaik, it's not in POSIX
> anywhere:
> http://www.in-ulm.de/~mascheck/various/shebang/

You forgot to mention that it's in AT Unix since 1979. I'd venture to
say that nowadays it is an integral part of Unix.

> So, magic dropped the ball - should've been identified as a shell
> script (due to the use of "echo"

Now you lost me.

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

iEYEARECAAYFAlZLjOgACgkQBcgs9XrR2kbCCQCeJuta2EiilKsRml49QQdRvgo2
lAIAn2ZaVmWvqAp6qi2i3AMArSLnaJGj
=HPu2
-END PGP SIGNATURE-

Re: how execute a script

[Luis Felipe Tabera Alonso]

On Tuesday 17 November 2015 20:21:23 Brian wrote:
> 
> I've also asked for a *concrete example* of a program not opening a file
> because of the lack of an extension. It hasn't yet been given.

$ gunzip file 
gzip: file: unknown suffix -- ignored

$mv file other.gz
$gunzip other.gz 
$ls
other

Re: how execute a script

[Brian]

On Tue 17 Nov 2015 at 14:57:58 -0500, shawn wilson wrote:

> On Tue, Nov 17, 2015 at 2:53 PM, Brian  wrote:
> > On Tue 17 Nov 2015 at 14:05:25 -0500, shawn wilson wrote:
> >
> >> On Tue, Nov 17, 2015 at 1:56 PM, Brian  wrote:
> >> > On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
> >> >
> >> >> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
> >> >>  wrote:
> >> >> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> >> >> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> >> >> >> > department has been trying for an hour".  Puzzled, because I 
> >> >> >> > thought I had
> >> >> >> > sent a .pdf, and had checked that it opened fine in Evince, I 
> >> >> >> > looked at
> >> >> >> the
> >> >> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When 
> >> >> >> > resent it
> >> >> >>
> >> >> >> communicated (via its extension). If you create a pdf, it is bad to 
> >> >> >> not
> >> >> >> have the pdf extension - you've lost data.
> >> >> >
> >> >> > How have you lost data?
> >> >>
> >> >> You loose what the file type (data) should be if you save a file w/o
> >> >> an extension. Again, this is fine for an installed program (no one
> >> >> cares as long as it works) but not so good for data that is processed
> >> >> by another program or a script I want to edit.
> >> >
> >> > You would have to give a specific example where a file processed by a
> >> > program or script fails to open for this argument to be convincing, You
> >> > also have to distinguish between data in the file and information the
> >> > extension conveys to the program.
> >>
> >> How about just that vim filetype relies on the filename to determine the 
> >> format?
> >
> > "vim filetype". I don't know what you mean. 'vim /usr/bin/vim' opens the
> > file.  I do not understand a word of the display but it does open it. An
> > extension doesn't seem to have a part to play in the file's opening.
> >
> 
> Your way of setting filetype is by looking at the extension - for example:
> :autocmd BufRead *.js set filetype=javascript
> 
> Same goes for *.pl or *.pm or *.py or *.c, etc

You have completely lost me now. You were the one who said

 You loose what the file type (data) should be if you save a file w/o   
 
 an extension.

I'm saying you do not need an extension to open a file.

I've also asked for a *concrete example* of a program not opening a file
because of the lack of an extension. It hasn't yet been given.

Re: how execute a script

[shawn wilson]

>  % file t.sh
> t.sh: ASCII text
>  % cat t.sh
> max=10
>

Oh and before someone says "but there's some standard that says you're
supposed to put a shebang at the top" - afaik, it's not in POSIX
anywhere:
http://www.in-ulm.de/~mascheck/various/shebang/

So, magic dropped the ball - should've been identified as a shell
script (due to the use of "echo"

Re: how execute a script

[Brian]

On Tue 17 Nov 2015 at 14:05:25 -0500, shawn wilson wrote:

> On Tue, Nov 17, 2015 at 1:56 PM, Brian  wrote:
> > On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
> >
> >> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
> >>  wrote:
> >> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> >> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> >> >> > department has been trying for an hour".  Puzzled, because I thought 
> >> >> > I had
> >> >> > sent a .pdf, and had checked that it opened fine in Evince, I looked 
> >> >> > at
> >> >> the
> >> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
> >> >>
> >> >> communicated (via its extension). If you create a pdf, it is bad to not
> >> >> have the pdf extension - you've lost data.
> >> >
> >> > How have you lost data?
> >>
> >> You loose what the file type (data) should be if you save a file w/o
> >> an extension. Again, this is fine for an installed program (no one
> >> cares as long as it works) but not so good for data that is processed
> >> by another program or a script I want to edit.
> >
> > You would have to give a specific example where a file processed by a
> > program or script fails to open for this argument to be convincing, You
> > also have to distinguish between data in the file and information the
> > extension conveys to the program.
> 
> How about just that vim filetype relies on the filename to determine the 
> format?

"vim filetype". I don't know what you mean. 'vim /usr/bin/vim' opens the
file.  I do not understand a word of the display but it does open it. An
extension doesn't seem to have a part to play in the file's opening.

> I suspect there are other examples where an extension might be
> *required* such as compression, but other than Windows, IDK off hand.

You haven't yet given an example of any such requirement in Debian.

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, Nov 16, 2015 at 10:37:28PM +, Lisi Reisz wrote:

[...]

> I take it those who are so against file endings are equally upset by 
> sources.list and menu.lst?

I don't know who "those who are so against file endings" are, in your mind.

To (preemptively) take myself out of this set, let me quote myself:

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

To recap, and simplifying very much. IMHO IMHO IMHO:

  executable script, independently of "interpreter" [1]
ending -> BAD
  shell, perl, any other (eg dynamic) library
ending -> GOOD
  pdf, jpeg, tar.gz
ending -> GOOD

> Though it is very annoying when they are *needed*.  Xsane usually puts them 
> in, and I used not to bother to check.  A few months ago I sent my lawyer a 
> scan of a document he needed.  An hour or two later, back came an 
> email:  "I'm so sorry, we have no software that can open that file.  The IT 
> department has been trying for an hour".  Puzzled, because I thought I had 
> sent a .pdf, and had checked that it opened fine in Evince, I looked at the 
> file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it opened 
> fine.

Software relying more on that ending than on what the user says ("believe me,
that *is* a pdf although the ending is not") is downright stupid, and you'll
find that more on Windows than on Linux (although Linux has a fair, and
increasing share of it).

I know this experience. Unless you name a file "foo.txt" stupid Word can't
open it (yeah, you can force it to, but Windows has "educated" its users
to be so helpless that they mostly wouldn't know how to). That's what I
was talking about when I mentioned "slavery".

Hope my point is clearer now.

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

iEYEARECAAYFAlZK3NAACgkQBcgs9XrR2kYhDACbB5F2VgQKSE72bPbp//asZ0Y3
Ey8An3rxzjSaAo3fCS0/zF4CIyIBCiBZ
=Ulbs
-END PGP SIGNATURE-

Re: how execute a script

[tomas]

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

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

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

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 2:53 PM, Brian  wrote:
> On Tue 17 Nov 2015 at 14:05:25 -0500, shawn wilson wrote:
>
>> On Tue, Nov 17, 2015 at 1:56 PM, Brian  wrote:
>> > On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
>> >
>> >> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>> >>  wrote:
>> >> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
>> >> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
>> >> >> > department has been trying for an hour".  Puzzled, because I thought 
>> >> >> > I had
>> >> >> > sent a .pdf, and had checked that it opened fine in Evince, I looked 
>> >> >> > at
>> >> >> the
>> >> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent 
>> >> >> > it
>> >> >>
>> >> >> communicated (via its extension). If you create a pdf, it is bad to not
>> >> >> have the pdf extension - you've lost data.
>> >> >
>> >> > How have you lost data?
>> >>
>> >> You loose what the file type (data) should be if you save a file w/o
>> >> an extension. Again, this is fine for an installed program (no one
>> >> cares as long as it works) but not so good for data that is processed
>> >> by another program or a script I want to edit.
>> >
>> > You would have to give a specific example where a file processed by a
>> > program or script fails to open for this argument to be convincing, You
>> > also have to distinguish between data in the file and information the
>> > extension conveys to the program.
>>
>> How about just that vim filetype relies on the filename to determine the 
>> format?
>
> "vim filetype". I don't know what you mean. 'vim /usr/bin/vim' opens the
> file.  I do not understand a word of the display but it does open it. An
> extension doesn't seem to have a part to play in the file's opening.
>

Your way of setting filetype is by looking at the extension - for example:
:autocmd BufRead *.js set filetype=javascript

Same goes for *.pl or *.pm or *.py or *.c, etc

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 2:57 PM, shawn wilson  wrote:
> On Tue, Nov 17, 2015 at 2:53 PM, Brian  wrote:
>> On Tue 17 Nov 2015 at 14:05:25 -0500, shawn wilson wrote:
>>
>>> On Tue, Nov 17, 2015 at 1:56 PM, Brian  wrote:
>>> > On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
>>> >
>>> >> On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
>>> >>  wrote:
>>> >> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
>>> >> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
>>> >> >> > department has been trying for an hour".  Puzzled, because I 
>>> >> >> > thought I had
>>> >> >> > sent a .pdf, and had checked that it opened fine in Evince, I 
>>> >> >> > looked at
>>> >> >> the
>>> >> >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent 
>>> >> >> > it
>>> >> >>
>>> >> >> communicated (via its extension). If you create a pdf, it is bad to 
>>> >> >> not
>>> >> >> have the pdf extension - you've lost data.
>>> >> >
>>> >> > How have you lost data?
>>> >>
>>> >> You loose what the file type (data) should be if you save a file w/o
>>> >> an extension. Again, this is fine for an installed program (no one
>>> >> cares as long as it works) but not so good for data that is processed
>>> >> by another program or a script I want to edit.
>>> >
>>> > You would have to give a specific example where a file processed by a
>>> > program or script fails to open for this argument to be convincing, You
>>> > also have to distinguish between data in the file and information the
>>> > extension conveys to the program.
>>>
>>> How about just that vim filetype relies on the filename to determine the 
>>> format?
>>
>> "vim filetype". I don't know what you mean. 'vim /usr/bin/vim' opens the
>> file.  I do not understand a word of the display but it does open it. An
>> extension doesn't seem to have a part to play in the file's opening.
>>
>
> Your way of setting filetype is by looking at the extension - for example:
> :autocmd BufRead *.js set filetype=javascript
>
> Same goes for *.pl or *.pm or *.py or *.c, etc

Here's another example of magic failing:

 % file t.sh

Downloads/temp swlap1
t.sh: ASCII text
 % cat t.sh

Downloads/temp swlap1
max=10

echo "HERE 1"
for (( count = 0; count <= max; count++ )) ; do
  echo "$count"
  sleep "${sleep:-0}"
done
echo "HERE 2"
 % ./t.sh

Downloads/temp swlap1
HERE 1
0
1
2
3
4
5
6
7
8
9
10
HERE 2

Re: how execute a script

[David Wright]

Excuse me for reversing your paragraphs.

On Tue 17 Nov 2015 at 18:56:40 (+), Brian wrote:
> On Tue 17 Nov 2015 at 13:08:49 -0500, shawn wilson wrote:
> 
> > On Tue, Nov 17, 2015 at 1:02 PM, Chris Bannister
> >  wrote:
> > > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> > >> On Nov 16, 2015 5:37 PM, "Lisi Reisz"  wrote:
> > >> > department has been trying for an hour".  Puzzled, because I thought I 
> > >> > had
> > >> > sent a .pdf, and had checked that it opened fine in Evince, I looked at
> > >> the
> > >> > file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it
> > >>
> > >> communicated (via its extension). If you create a pdf, it is bad to not
> > >> have the pdf extension - you've lost data.
> > >
> > > How have you lost data?
> > 
> > You loose what the file type (data) should be if you save a file w/o
> > an extension. Again, this is fine for an installed program (no one
> > cares as long as it works) but not so good for data that is processed
> > by another program or a script I want to edit.

> My example: gv does not recognise the PDF file 'test' as something it is
> *capable of opening*. With 'test' as the only file in a directory the
> command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
> opens the file, which is all that matters.

My reaction on reading this was "that's the falt of shell completion".
After all, TAB completion, like globbing, is something that's done
before gv gets a look-in, isn't it.

In the past, I have tried to use completion when (unwisely) typing
dpkg -i (after all, who wants to type .deb filenames in full) and
failed, using the "less" command instead, and then changing
less→dpkg -i last thing.

(Aside: it also annoys me that something that will complete after a >
won't complete after a >| for some reason. As I have set -o noclobber
I have to complete after > and then insert the | last thing.)

My second reaction was to try it. It didn't work. I could type
gv /tmp/j   and get gv /tmp/jj/jupe completed for me.
I did test that gv wasn't fooled by giving it the same pdf file
as jupe.ps jupe.jpg etc.

> program or script fails to open for this argument to be convincing, You
> also have to distinguish between data in the file and information the
> extension conveys to the program.
> 
> Your example is?

Well, the obvious one is gcc:

$ gcc lsls.c ← writes a.out which I now delete.
$ gcc lsls.s 
lsls.s: Assembler messages:
lsls.s:8: Error: junk `(int argc,char* argv[])' after expression
lsls.s:8: Error: operand size mismatch for `int'
lsls.s:9: Error: junk at end of line, first unrecognized character is `{'
lsls.s:10: Error: no such instruction: `dir *mydir'

etc.

$ gcc lsls
lsls: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
$ 

Cheers,
David.

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 06:56:40PM +, Brian wrote:

[...]

> My example: gv does not recognise the PDF file 'test' as something it is
> *capable of opening*. With 'test' as the only file in a directory the
> command gv plus TAB completion doesn't produce 'gv test'. But 'gv test'
> opens the file, which is all that matters.

The TAB thing is your shell's autocompletion talking, gv isn't involved.
And yes, shell's autocompletion usually relies on the file name pattern
(dot-ending, aka "extension" is but a special case of that).

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

iEYEARECAAYFAlZLi7EACgkQBcgs9XrR2ka8HgCbBKW4jJK6INnHZaYl1xo58ZWw
CU8An002qe4/8uEKJzkjp5pk12k4rT1+
=Z7IW
-END PGP SIGNATURE-

Re: how execute a script

[John Hasler]

shawn wilson wrote:
> Oh and before someone says "but there's some standard that says you're
> supposed to put a shebang at the top" - afaik, it's not in POSIX
> anywhere:
> http://www.in-ulm.de/~mascheck/various/shebang/

tomas writes:
> You forgot to mention that it's in AT Unix since 1979. I'd venture to
> say that nowadays it is an integral part of Unix.

In fact the shebang in ASCII is the magic number for a shell script.  I
think that the relevant standard would be the SUS.
-- 
John Hasler 
jhas...@newsguy.com
Elmwood, WI USA

Re: how execute a script

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Nov 17, 2015 at 04:13:48PM -0500, shawn wilson wrote:
> On Tue, Nov 17, 2015 at 3:24 PM,   wrote:

[...]

> > Now you lost me.
> >
> 
> If magic were smarter (was able to derive from syntax or had regex
> capability in the format), it could've still told me I was looking at
> a script (and not just a bunch of text - which is next to useless). It
> doesn't, so arguing that magic could be used (not an argument I've
> seen, but one I was expecting and figured I'd preempt) instead of an
> extension is lacking.

Got it. But magic *can* do many of those things. A headless shell
script is a tough nut to crack, though: "echo" could occur as well
in a Tcl script (via Tcl's crazy but genius "unknown" mechanism).

Start here[1] if you want to have some fun :-)

[1] 

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

iEYEARECAAYFAlZLm2MACgkQBcgs9XrR2kZQaACfUEYXN1YCBt94CoWABtYuzl+v
AsUAn04zBdR0IFSEy/As5nnHii3/ixU0
=gzE/
-END PGP SIGNATURE-

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 3:24 PM,   wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, Nov 17, 2015 at 03:15:21PM -0500, shawn wilson wrote:
>> >  % file t.sh
>> > t.sh: ASCII text
>> >  % cat t.sh
>> > max=10
>> >
>>
>> Oh and before someone says "but there's some standard that says you're
>> supposed to put a shebang at the top" - afaik, it's not in POSIX
>> anywhere:
>> http://www.in-ulm.de/~mascheck/various/shebang/
>
> You forgot to mention that it's in AT Unix since 1979. I'd venture to
> say that nowadays it is an integral part of Unix.
>

Merely pointing out it's not a spec. But yeah, it's older than me :)

>> So, magic dropped the ball - should've been identified as a shell
>> script (due to the use of "echo"
>
> Now you lost me.
>

If magic were smarter (was able to derive from syntax or had regex
capability in the format), it could've still told me I was looking at
a script (and not just a bunch of text - which is next to useless). It
doesn't, so arguing that magic could be used (not an argument I've
seen, but one I was expecting and figured I'd preempt) instead of an
extension is lacking.

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 4:25 PM,   wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tue, Nov 17, 2015 at 04:13:48PM -0500, shawn wilson wrote:
>> On Tue, Nov 17, 2015 at 3:24 PM,   wrote:
>
> [...]
>
>> > Now you lost me.
>> >
>>
>> If magic were smarter (was able to derive from syntax or had regex
>> capability in the format), it could've still told me I was looking at
>> a script (and not just a bunch of text - which is next to useless). It
>> doesn't, so arguing that magic could be used (not an argument I've
>> seen, but one I was expecting and figured I'd preempt) instead of an
>> extension is lacking.
>
> Got it. But magic *can* do many of those things. A headless shell
> script is a tough nut to crack, though: "echo" could occur as well
> in a Tcl script (via Tcl's crazy but genius "unknown" mechanism).
>

You're right - just "script" then. I'm not dissing magic - it's a good
starting point in forensics or to see what's in a bin directory, but
shouldn't be relied on (also see ftimes xmagic for a more featureful
magic implementation w/e sf comes back up).

My point is that you can't determine what you're looking at w/o being
told (an extension) or looking at it. So (my original point) you loose
data by removing/not having an extension.

Re: how execute a script

[shawn wilson]

On Tue, Nov 17, 2015 at 5:17 PM, shawn wilson  wrote:

> shouldn't be relied on (also see ftimes xmagic for a more featureful
> magic implementation w/e sf comes back up).

Ugh, it's back now:

http://ftimes.sourceforge.net/FTimes/XMagic.shtml

Re: how execute a script

[David Wright]

On Mon 16 Nov 2015 at 10:09:04 (+0100), to...@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), to...@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), to...@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 

Re: how execute a script

[David Wright]

On Mon 16 Nov 2015 at 06:54:40 (+0100), Martin Str|mberg wrote:
> In article  David Wright 
>  wrote:
> > 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.
> 
> Perhaps it's because (MS)DOS begat WINDOWS that only knew how to run
> something based on the extension?
> 
> And that is why we shudder on the sight of a (unnecessary?) extension?

I wouldn't know. My experience of windows is far less than DOS, and my
use of DOS was pretty much restricted to an AUTOEXEC.BAT that started
an emulation system which was my area of expertise. Interesting choice
of language, though; shudder.

I'm the person questioning the relevance of DOS to putting ".sh" at
the end of an on-PATH executable script's filename, when DOS was
brought up in https://lists.debian.org/debian-user/2015/11/msg00453.html

I take it there's a whole generation of folk who gained their
experience of filename endings (a less loaded word than extension)
through DOS/windows, perhaps entirely so. With it, they picked up a
load of negative associations, causing shuddering here and unhappiness
in another part of this thread.

I'm sorry for you. I didn't touch DOS until 1992-06-01 (to be precise)
about twentyone years into my computing career. To say I *used* it
would be an overstatement: I ran one package on it.

Putting meaningful endings onto filenames (excepting, I hasten to
add lest people jump down my throat, executable scripts) had been a
way of life for years. Their necessity was variable from system to
system; sometimes they were just a convention. Look at   man gcc.
It has meaningful endings. They've been there since at least
15 March 1972 when, allegedly, the number of Unix installations had
grown to 10. (At that time, gcc was obviously called cc; Stallman
hadn't yet graduated.)

As for unix scripts, well, yes, there's no *need* for any endings,
but that doesn't preclude their use. If that makes you unhappy or
into a shudderer, please get over it.

Cheers,
David.

Re: how execute a script

[Lisi Reisz]

On Monday 16 November 2015 19:33:51 David Wright wrote:
> On Mon 16 Nov 2015 at 06:54:40 (+0100), Martin Str|mberg wrote:
> > In article  David Wright 
 wrote:
> > > 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.
> >
> > Perhaps it's because (MS)DOS begat WINDOWS that only knew how to run
> > something based on the extension?
> >
> > And that is why we shudder on the sight of a (unnecessary?) extension?
>
> I wouldn't know. My experience of windows is far less than DOS, and my
> use of DOS was pretty much restricted to an AUTOEXEC.BAT that started
> an emulation system which was my area of expertise. Interesting choice
> of language, though; shudder.
>
> I'm the person questioning the relevance of DOS to putting ".sh" at
> the end of an on-PATH executable script's filename, when DOS was
> brought up in https://lists.debian.org/debian-user/2015/11/msg00453.html
>
> I take it there's a whole generation of folk who gained their
> experience of filename endings (a less loaded word than extension)
> through DOS/windows, perhaps entirely so. With it, they picked up a
> load of negative associations, causing shuddering here and unhappiness
> in another part of this thread.
>
> I'm sorry for you. I didn't touch DOS until 1992-06-01 (to be precise)
> about twentyone years into my computing career. To say I *used* it
> would be an overstatement: I ran one package on it.
>
> Putting meaningful endings onto filenames (excepting, I hasten to
> add lest people jump down my throat, executable scripts) had been a
> way of life for years. Their necessity was variable from system to
> system; sometimes they were just a convention. Look at   man gcc.
> It has meaningful endings. They've been there since at least
> 15 March 1972 when, allegedly, the number of Unix installations had
> grown to 10. (At that time, gcc was obviously called cc; Stallman
> hadn't yet graduated.)
>
> As for unix scripts, well, yes, there's no *need* for any endings,
> but that doesn't preclude their use. If that makes you unhappy or
> into a shudderer, please get over it.

I take it those who are so against file endings are equally upset by 
sources.list and menu.lst?
 
Though it is very annoying when they are *needed*.  Xsane usually puts them 
in, and I used not to bother to check.  A few months ago I sent my lawyer a 
scan of a document he needed.  An hour or two later, back came an 
email:  "I'm so sorry, we have no software that can open that file.  The IT 
department has been trying for an hour".  Puzzled, because I thought I had 
sent a .pdf, and had checked that it opened fine in Evince, I looked at the 
file - groaned - and renamed scan-foo to scan-foo.pdf.  When resent it opened 
fine.

Lisi

Re: how execute a script

[shawn wilson]

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"  wrote:

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

Re: how execute a script

[David Wright]

On Sat 14 Nov 2015 at 08:00:20 (+0100), to...@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), to...@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.

Re: how execute a script

[Martin Str|mberg]

In article  David Wright 
 wrote:
> 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.

Perhaps it's because (MS)DOS begat WINDOWS that only knew how to run
something based on the extension?

And that is why we shudder on the sight of a (unnecessary?) extension?


-- 
MartinS

Re: how execute a script

[Chris Bannister]

On Mon, Nov 16, 2015 at 06:54:40AM +0100, Martin Str|mberg wrote:
> In article  David Wright 
>  wrote:
> > 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.
> 
> Perhaps it's because (MS)DOS begat WINDOWS that only knew how to run
> something based on the extension?

That's what I understood the comment to mean.

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X

Re: how execute a script

[Pol Hallen]

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


thanks for help but does not work :-/

Pol

Re: how execute a script

[David Wright]

On Fri 13 Nov 2015 at 14:43:39 (+0100), to...@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.

Re: how execute a script

[Don Armstrong]

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

Re: how execute a script

[David Wright]

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.

Re: how execute a script

[Don Armstrong]

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

Re: how execute a script

[Lotek]

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

Re: how execute a script

[David Wright]

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.

Re: how execute a script

[tomas]

-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), to...@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-

Re: how execute a script

[Pol Hallen]

  (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

how execute a script

[Pol Hallen]

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

Re: how execute a script

[Darac Marjal]

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


What is your evidence for the statement that it "does not run"? Are 
there any error messages, or do the actions in the script merely not 
happen?


Is ~/bin/script1.sh executable? Does it have a suitable shebang line 
(#!/bin/sh) at the start (and no UTF-8 bom)?




any idea?

thanks for help! :-)

Pol



-- For more information, please reread.


signature.asc
Description: PGP signature

Re: how execute a script

[tomas]

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

Re: how execute a script

[Gene Heskett]

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 

Re: how execute a script

[Gene Heskett]

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