Subject: Re: The "*" character (was: Latex )

From: "Susan G. Kleinmann" <[email-masked]>
Date: Wed, 07 Aug 1996 21:13:58 -0400

Hi Mark --
You said:
> in response to: 
> >Hi Mark --
> >You asked:
> >> because I'd said:
> >> >It would be helpful if you could tell us what version of the packages
> >> >you have installed.  For example, if you would run this commands:
> >> >
> >> >      dpkg -l *tex*
> >> 
> >> I noticed that this doesn't work under tcsh, but does work under
> >> bash.  Is there a difference between how the * character is treated
> >> under the two shells?
> >
> >
> >What I'd written was actually not right for either shell.
> >
> >I should have written:
> >
> >         dpkg -l "*tex*"
> >
> >The problem is that without the quotes, the shell expands the argument
> >first, before handing it to dpkg.  If there's a file in your current
> >directory with a name that matches *tex*, then that file, and only that
> >file, is fed to dpkg.  This is not what's intended of course.
> >
> >So I tried the correct usage (with the quotes) under tcsh and it worked
> >fine.
> 
> But the interesting thing is that dpkg -l *tex* actually _works_ when
> run under bash, leading me to think that the bash shell doesn't expand
> the argument first.
> 
Are you sure you tried dpkg -l *tex* in a directory where you know there's 
a file whose name matches the pattern *tex*, and whose name is not that 
of a debian package?  On my system both bash and tcsh behaved the same way.

Susan

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Thu, 08 Aug 1996 08:18:36 -0400

Hi Mark --

You said:
> Very strange.  Here is what I did on my system under bash:
> 
> (mark, destiny)$ ls
> Maelstrom        gnuchessc        maelstrom        xonix
> Maelstrom_sound  gnuchessn        mirrormagic      xp-replay
> acm              gnuchessr        nethack          xpat2
> acms             gnuchessx        postprint        xpilot
> cmail            gnugo            pxboard          xpilots
> fortune          gnushogi         xasteroids       xshogi
> game             gnushogir        xbattle          xsok
> gnuan            gnushogix        xboard           xtet42
> gnuchess         kill-acms        xinvaders        xtron
> (mark, destiny)$ dpkg -l *tex*
> Desired=Unknown/Install/Remove/Purge
> | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
> |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=ba
d)
> ||/ Name            Version        Description
> +++-===============-==============-==========================================
==
> un  X11-text-viewer <none>         (no description available)
> pn  amslatex        <none>         (no description available)
> pn  amstex          <none>         (no description available)
> pn  auctex          <none>         (no description available)
> pn  bibtex          <none>         (no description available)
> pn  gettext         <none>         (no description available)
> pn  hyperlatex      <none>         (no description available)
> pn  latex           <none>         (no description available)
> pn  latex2e-doc     <none>         (no description available)
> pn  latex2rtf       <none>         (no description available)
> ii  nb-tex          2.1-1          NTeX package
> ii  nb-texi         2.1-1          NTeX package
> ii  ntex            2.1-1          NTeX package
> ii  nx-etex         2.1-1          NTeX package
> ii  nx-mtex         2.1-1          NTeX package
> un  tex             <none>         (no description available)
> pn  texbin          <none>         (no description available)
> pn  texidoc         <none>         (no description available)
> ii  texinfo         3.7-1          The GNU Project's documentation formatting
 s
> pn  texlib          <none>         (no description available)
> pn  texpsfnt        <none>         (no description available)
> pn  textfm          <none>         (no description available)
> ii  textutils       1.19-1         The GNU text file processsing utilities.
> ii  untex           9210-4         Remove LaTeX commands from input.
> 
> 
> (Which incidently is the same as what I get when I use the quotes)
> 

What you got was correct.

Your directory listing shows no files which match *tex*.  Therefore,
the shell couldn't expand *tex* to anything in your directory, and 
therefore passed the string *tex* to dpkg, which expanded it on its own.

If:
-- you have a file whose name matches *tex* in the current working directory,
   AND
   if the name of that file _is not_ the name of a Debian package, 

   then dpkg wouldn't be able to infer its status.  You'd get a message 
   "No packages found matching <whatever file you had that matched *tex*>."

-- you have a file whose name matches *tex* in the current working directory,
   AND
   if the name of the file _is_ the name of a Debian package,

   then dpkg -l would be able to look up its status and report it.

-- you do not have a file whose name matches *tex* in the current working 
   directory,

   then the shell passes *tex* to dpkg, which expands the regexp in its
   administrative directories.

HTH,
Susan

---

From: Mark Phillips <[email-masked]>
Date: Thu, 08 Aug 1996 11:28:50 +1000

(mark, destiny)$ ls
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
+++-===============-==============-============================================
ii  texinfo         3.7-1          The GNU Project's documentation formatting s

Mark.

---

From: Mark Phillips <[email-masked]>
Date: Thu, 08 Aug 1996 10:34:27 +1000

Thanks,

Mark.

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Wed, 07 Aug 1996 20:51:08 -0400

Hi Mark --

I should have written:

         dpkg -l "*tex*"

Cheers,
Susan

---

From: Mark Phillips <[email-masked]>
Date: Thu, 08 Aug 1996 10:59:50 +1000

Mark.

---

From: Gerry Toll <[email-masked]>
Date: Thu, 08 Aug 1996 10:54:57 -0400

Mark,

When using wildcards in bash, the shell attempts to expand them, but 
if it finds nothing that matches the specified pattern, it passes the 
wildcard string to the command. Quoting the wildcard pattern causes 
the shell to pass it as a single argument to the command. 

In your case, since there was no file in the directory you were 
executing from that matched the pattern *tex*, bash behaved as if you 
had quoted the pattern.

Since I don't use tcsh, I couldn't say for certain, but my 
understanding is that it treats wildcards in a slightly different 
manner - always attempting the expansion and returning an error 
message if the no matches are found. To pass an argument containing 
wildcards, the pattern must be quoted. This would explain why:

bash$ dpkg -l *tex*   

worked, and:

tcsh% dpkg -l *tex* 

did not.

In any case, as a matter of good style, you should always quote 
wildcards when you don't want them expanded - even if you know you 
can get away without it. 

Hope this clarifies things...

Gerry

---

From: [email-masked] (Heiko Schlittermann)
Date: Thu, 8 Aug 1996 13:39:09 +0200 (MET DST)

Mark Phillips wrote:
: 
: >you have installed.  For example, if you would run this commands:
: >      dpkg -l *tex*
: I noticed that this doesn't work under tcsh, but does work under
: bash.  Is there a difference between how the * character is treated
: under the two shells?

Under sh-lish shells `*' expands to all files, if any, or to '*'
itsself, if no files/dirs match.

Under csh-lish shells `*' expands to all files, if any, or to _nothing_
(and a note `no match') if nothing matches.

AFAIK ...

    Heiko
--
email : [email-masked] [email-masked] [email-masked]
pgp   : A1 7D F6 7B 69 73 48 35  E1 DE 21 A7 A8 9A 77 92 
finger: [email-masked]         [email-masked]

---

From: Guy Maor <[email-masked]>
Date: Thu, 8 Aug 1996 10:53:22 -0500 (CDT)

> bash.  Is there a difference between how the * character is treated

Yes, there is a difference when the globbing doesn't expand to
anything.  In this case bash passes the word with the wildcards while
tcsh just errors.  For example:

$ ls
$ echo *tex*
*tex*
$ ./nosuchfile *tex*
bash: ./nosuchfile: No such file or directory.
$ tcsh
> echo *tex*
echo: No match.
> ./nosuchfile *tex*
./nosuchfile: No match.

tcsh is pretty broken to issue make it seem as if commands that don't
exist are issuing errors.

Guy

---

From: Philippe Troin <[email-masked]>
Date: Thu, 08 Aug 1996 09:20:46 -0700

On Thu, 08 Aug 1996 10:34:27 +1000 Mark Phillips ([email-masked].
> bash.  Is there a difference between how the * character is treated

By default, bash expands shell metacharacters (*?[]) only if they're a match ({} rules are the exception, they're always expanded). Otherwise, bash passes the metacharacters to the invoked program.
Tcsh will complain and abort if it cannot expand some metacharacters. You need to quote them.

Solution: always quote shell metacharacters when you want to pass them to a program.

Phil.

---

From: [email-masked] (Bernd Eckenfels)
Date: Thu, 8 Aug 1996 20:06:57 +0200 (MET DST)

> bash.  Is there a difference between how the * character is treated

'*tex*' works with both shells. bash will not replace a clobber pattern with
the empty string if no match is found, tcsh does (AFAIK).

bash(1)
#   Pathname Expansion
#       After word splitting, unless the -f option has  been  set,
#       bash  scans  each word for the characters *, ?, and [.  If
#       one of these characters appears, then the word is regarded
#       as  a  pattern, and replaced with an alphabetically sorted
#       list of pathnames matching the pattern.   If  no  matching
#       pathnames    are    found,    and   the   shell   variable
#       allow_null_glob_expansion  is  unset,  the  word  is  left
#       unchanged.   If  the  variable  is set, and no matches are
#       found, the word is removed.  When a pattern  is  used  for
#       pathname  generation, the character `.''  at the start of
#       a name or immediately following a slash  must  be  matched
#       explicitly,  unless  the shell variable glob_dot_filenames
#       is set.   The  slash  character  must  always  be  matched
#       explicitly.   In  other cases, the `.''  character is not
#       treated specially.

and

bash(1) set
#              -u      Treat unset variables as an error when per-
#                      forming parameter expansion.  If  expansion
#                      is  attempted  on  an  unset  variable, the
#                      shell prints an error message, and, if  not
#                      interactive,  exits with a non-zero status.
#

Greetings
Bernd
-- 
  (OO)      -- [email-masked] --
 ( .. )  ecki@lina.{inka.de,ka.sub.org}  http://home.pages.de/~eckes/
  o--o     *plush*  2048/A2C51749  eckes@irc  +4972573817  *plush*
(O____O)       If privacy is outlawed only Outlaws have privacy

---

From: Yves Arrouye <[email-masked]>
Date: Fri, 9 Aug 1996 01:45:49 +0200

> bash.  Is there a difference between how the * character is treated

It differs from shell to shell and even within a given shell:

	marin215# tcsh
	# echo *tex*
	echo: No match.
	# set nonomatch
	# echo *tex*
	*tex*
	#

In csh, having nonomatch set asks the shell not to say it can't do a
wildcard expansion but rather to pass the argument (as if it was
quoted, then) to the command.

The surest way to get consistent results is to quote ;-)

Yves.

---

From: Mark Eichin <[email-masked]>
Date: 08 Aug 1996 21:00:18 -0400

if you prefer the bash behavior of ignoring the pattern failure, just
	set nonomatch
in tcsh or csh.