public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* [cygwin]bash question, perhaps problem
@ 2002-06-25 13:42 bruno patin
  2002-06-26  7:15 ` Randall R Schulz
  0 siblings, 1 reply; 5+ messages in thread
From: bruno patin @ 2002-06-25 13:42 UTC (permalink / raw)
  To: Cygwin





if you consider the simple script

---------------------
#!/bin/bash
echo $0
-----------------------

the line do give normally the exact text you use to execute the command
(see the man pages of bash). but, on cygwin, we have, when executed from
a distant directory by a relative call, the absolute name. So we can't
use this name to return from the local directory to where this command
was launched.

is it a known bug, is it nominal ?

thanks for your great work


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [cygwin]bash question, perhaps problem
  2002-06-25 13:42 [cygwin]bash question, perhaps problem bruno patin
@ 2002-06-26  7:15 ` Randall R Schulz
  2002-06-26 18:04   ` RE : " bruno patin
  0 siblings, 1 reply; 5+ messages in thread
From: Randall R Schulz @ 2002-06-26  7:15 UTC (permalink / raw)
  To: bruno patin, Cygwin

Bruno,

This is not a bug.

It has never been proper to examine $0 / argv[0] to determine anything 
about the current working directory in which a command was invoked.

In scripts, that's what "pwd" (built-in) or "/bin/pwd" (executable) is for. 
Unless something in the ".bashrc" file is changing the current directory (a 
very dubious practice), the current working directory at the time the 
script's commands begin executing will be the same as that in which the 
script was invoked.

Perhaps I misunderstand your words. I you want to know where the invoked 
script is located based on $0, you can (in BASH only) use this:

scriptDir="${0%/*}"

For details of this and related variable expansion / substitution syntax, 
see the section titled "Shell Parameter Expansion" in the BASH manual 
(simply "Parameter Expansion" in the BASH man page).

Randall Schulz
Mountain View, CA USA


At 12:58 2002-06-25, bruno patin wrote:

>if you consider the simple script
>
>---------------------
>#!/bin/bash
>echo $0
>-----------------------
>
>the line do give normally the exact text you use to execute the command
>(see the man pages of bash). but, on cygwin, we have, when executed from
>a distant directory by a relative call, the absolute name. So we can't
>use this name to return from the local directory to where this command
>was launched.
>
>is it a known bug, is it nominal ?
>
>thanks for your great work


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE : [cygwin]bash question, perhaps problem
  2002-06-26  7:15 ` Randall R Schulz
@ 2002-06-26 18:04   ` bruno patin
  2002-06-27  9:22     ` RE : bash " Joe Buehler
  0 siblings, 1 reply; 5+ messages in thread
From: bruno patin @ 2002-06-26 18:04 UTC (permalink / raw)
  To: 'Randall R Schulz'; +Cc: Cygwin



-----Message d'origine-----
De : Randall R Schulz [mailto:rrschulz@cris.com] 
Envoyé : mercredi 26 juin 2002 14:30
À : bruno patin; Cygwin
Objet : Re: [cygwin]bash question, perhaps problem


Bruno,

This is not a bug.

It has never been proper to examine $0 / argv[0] to determine anything 
about the current working directory in which a command was invoked.


Randall,

If I look at the bash manual page (or sh page for this matter), I see
for the $0 expansion what is written under. What I understood (perhaps
badly) is that $0 (unless -c is used) give me the exact invocation of
the shell so If I take my example, suppose we are in the local directory
and I call the script toto, if called ./toto, $0 will be equal to ./toto
and if I invoked the script from another directory, say the build
directory by ../toto, then $0 will be equal to ../toto. What I saw is
that under the local directory, $0 is equal to ./toto but under the
build directory $0 is equal to /home/xxxxx/toto.

The problem we have is that we use a root value obtained by pwd and
append to it what is given to us by the $0 variable.

I prefer to explain a little more my "problem" (we worked a workaround
but It's for comprehension of the manual pages and what I wait from the
bash) as perhaps you don't understand what I meant (my english is poor I
fear).

Thanks for the help

------------man page extract---------------------
0
Expands to the name of the shell or shell script. This is set at shell
initialization. If Bash is invoked with a file of commands (see section
Shell Scripts), $0 is set to the name of that file. If Bash is started
with the `-c' option (see section Invoking Bash), then $0 is set to the
first argument after the string to be executed, if one is present.
Otherwise, it is set to the filename used to invoke Bash, as given by
argument zero.
--------------------------------------------------



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: RE : bash question, perhaps problem
  2002-06-26 18:04   ` RE : " bruno patin
@ 2002-06-27  9:22     ` Joe Buehler
  0 siblings, 0 replies; 5+ messages in thread
From: Joe Buehler @ 2002-06-27  9:22 UTC (permalink / raw)
  To: cygwin

bruno patin wrote:

> The problem we have is that we use a root value obtained by pwd and
> append to it what is given to us by the $0 variable.

I may misremember, but I think that at least one older UNIX version
did not use to provide the name of the script in $0.  I believe it
was a version of System V that would actually give you something like
/dev/fd/7 for $0.

A Google search for "argv /dev/fd" in fact yielded the following from
what appears to be an IRIX man page for the exec() system call:

Set-user-ID, set-group-ID interpreter files and those with	attached
capabilities are handled in a special manner.  If execution of an
interpreter file will change either the user or group ID or the file has
attached capabilities, IRIX will open the interpreter file	for reading
(subject to the read permissions of the interpreter file and the user and
group ID of the new process).   A pathname	corresponding to the
interpreter file descriptor will be substituted for the pathname of the
interpreter file in the argument list passed to the intepreter.  This
pathname will be of the form /dev/fd/N where N is the number of the
interpreter file descriptor.

It may work on the systems you usually use, but it's not portable.

Joe Buehler




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [cygwin]bash question, perhaps problem
@ 2002-06-25 15:59 bruno patin
  0 siblings, 0 replies; 5+ messages in thread
From: bruno patin @ 2002-06-25 15:59 UTC (permalink / raw)
  To: Cygwin




-----Message d'origine-----
De : Jon LaBadie [mailto:jcyg@jgcomp.com] 
Envoyé : mardi 25 juin 2002 20:08
À : bruno patin
Objet : Re: [cygwin]bash question, perhaps problem


On Tue, Jun 25, 2002 at 08:58:31PM +0100, bruno patin wrote:
> 
> if you consider the simple script
> 
> ---------------------
> #!/bin/bash
> echo $0
> -----------------------
> 
> the line do give normally the exact text you use to execute the
> command (see the man pages of bash). but, on cygwin, we have, when 
> executed from a distant directory by a relative call, the absolute 
> name. So we can't use this name to return from the local directory to 
> where this command was launched.
> 
> is it a known bug, is it nominal ?

While I feel it is a bug (btw, same thing happens with ksh93 I added), I
fail to see how it affects your cd'ing.

In fact, we use the autoconf/automake tools and we use the a variable
that is given to us by the position of the command as we build the
product in another place. This permit usq to know where is the root of
the package. With this bug the first argument gives an absolute path so
the configure script writes false path.

Thanks for the help.

Bruno patin


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-06-27 15:18 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-06-25 13:42 [cygwin]bash question, perhaps problem bruno patin
2002-06-26  7:15 ` Randall R Schulz
2002-06-26 18:04   ` RE : " bruno patin
2002-06-27  9:22     ` RE : bash " Joe Buehler
2002-06-25 15:59 [cygwin]bash " bruno patin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).