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

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

Re: how execute a script

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: how execute a script Martin Str|mberg <ams@ludd.luth.se> - 2015-11-16 07:00 +0100
    Re: how execute a script Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-16 07:30 +0100
    Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-16 20:40 +0100
      Re: how execute a script Lisi Reisz <lisi.reisz@gmail.com> - 2015-11-16 23:40 +0100
        Re: how execute a script <tomas@tuxteam.de> - 2015-11-17 09:30 +0100
        Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 15:40 +0100
          Re: how execute a script Chris Bannister <cbannister@slingshot.co.nz> - 2015-11-17 19:10 +0100
            Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 19:10 +0100
              Re: how execute a script Elimar Riesebieter <riesebie@lxtec.de> - 2015-11-17 19:30 +0100
                Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 20:10 +0100
              Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-17 20:00 +0100
                Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 20:10 +0100
                  Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-17 21:00 +0100
                    Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 21:00 +0100
                      Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 21:10 +0100
                        Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 21:20 +0100
                          Re: how execute a script <tomas@tuxteam.de> - 2015-11-17 22:00 +0100
                            Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 22:20 +0100
                              Re: how execute a script tomas@tuxteam.de - 2015-11-17 23:10 +0100
                                Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 23:20 +0100
                                  Re: how execute a script shawn wilson <ag4ve.us@gmail.com> - 2015-11-17 23:30 +0100
                                  Re: how execute a script tomas@tuxteam.de - 2015-11-18 09:10 +0100
                            Re: how execute a script John Hasler <jhasler@newsguy.com> - 2015-11-17 22:40 +0100
                      Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-17 21:30 +0100
                        Re: how execute a script Luis Felipe Tabera Alonso <taberalf@unican.es> - 2015-11-17 22:10 +0100
                          Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-18 00:10 +0100
                            Re: how execute a script Don Armstrong <don@debian.org> - 2015-11-18 01:10 +0100
                            Re: how execute a script <tomas@tuxteam.de> - 2015-11-18 09:30 +0100
                              Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-18 16:00 +0100
                                Re: how execute a script <tomas@tuxteam.de> - 2015-11-18 16:20 +0100
                                  Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-18 16:40 +0100
                Re: how execute a script David Wright <deblis@lionunicorn.co.uk> - 2015-11-17 21:20 +0100
                Re: how execute a script <tomas@tuxteam.de> - 2015-11-17 22:00 +0100
                  Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-18 00:10 +0100
                    Re: how execute a script <tomas@tuxteam.de> - 2015-11-18 09:30 +0100
                      Re: how execute a script Brian <ad44@cityscape.co.uk> - 2015-11-18 13:50 +0100
            Re: how execute a script <tomas@tuxteam.de> - 2015-11-17 19:20 +0100

Page 2 of 2 — ← Prev page 1 [2]

#160706

On Tue, Nov 17, 2015 at 5:17 PM, shawn wilson <ag4ve.us@gmail.com> 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

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

#160718

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

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

#160703

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&T 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 
jhasler@newsguy.com
Elmwood, WI USA

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

#160698

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

> On Tue, Nov 17, 2015 at 2:53 PM, Brian <ad44@cityscape.co.uk> wrote:
> > On Tue 17 Nov 2015 at 14:05:25 -0500, shawn wilson wrote:
> >
> >> On Tue, Nov 17, 2015 at 1:56 PM, Brian <ad44@cityscape.co.uk> 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
> >> >> <cbannister@slingshot.co.nz> wrote:
> >> >> > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> >> >> >> On Nov 16, 2015 5:37 PM, "Lisi Reisz" <lisi.reisz@gmail.com> 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.

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

#160701

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

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

#160708

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.

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

#160712

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

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

#160720

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

On Tue, Nov 17, 2015 at 11:08:46PM +0000, 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-----

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

#160739

On Wed 18 Nov 2015 at 08:47:59 (+0100), tomas@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.

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

#160743

-----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), tomas@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-----

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

#160745

On Wed 18 Nov 2015 at 15:42:44 (+0100), tomas@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), tomas@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.

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

#160696

Excuse me for reversing your paragraphs.

On Tue 17 Nov 2015 at 18:56:40 (+0000), 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
> > <cbannister@slingshot.co.nz> wrote:
> > > On Tue, Nov 17, 2015 at 09:31:53AM -0500, shawn wilson wrote:
> > >> On Nov 16, 2015 5:37 PM, "Lisi Reisz" <lisi.reisz@gmail.com> 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 <TAB> <TAB> 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.

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

#160700

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

On Tue, Nov 17, 2015 at 06:56:40PM +0000, 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-----

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

#160707

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

> On Tue, Nov 17, 2015 at 06:56:40PM +0000, 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?

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

#160721

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

On Tue, Nov 17, 2015 at 11:08:24PM +0000, Brian wrote:
> On Tue 17 Nov 2015 at 21:18:57 +0100, tomas@tuxteam.de wrote:
> 
> > On Tue, Nov 17, 2015 at 06:56:40PM +0000, 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-----

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

#160733

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

> On Tue, Nov 17, 2015 at 11:08:24PM +0000, Brian wrote:
> > On Tue 17 Nov 2015 at 21:18:57 +0100, tomas@tuxteam.de wrote:
> > 
> > > On Tue, Nov 17, 2015 at 06:56:40PM +0000, 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.

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

#160680

-----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" <lisi.reisz@gmail.com> 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-----

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web