/bin/pwd versus built-in pwd

/bin/pwd versus built-in pwd

[Fred Kulack]

I just upgraded from an older cygwin 1.1.x release to the current one.

It use to be that I could use /bin/pwd instead of the bash built-in
If I wanted to get the full directory name of the cwd instead
of the softlink name.

For example, in the following,
 > ls -ld //f/kulack/l/jdb44
lrw-r--r--   1 kulack   None           85 Sep 26 14:51 //f/kulack/l/jdb44
->
//W/as400/v4r4m0.java/cur/cmvc/java.pgm/jdb.java/src/com/ibm/db2/jdbc/app/

pwd would give /cygdrive/f/
/bin/pwd would give
/cygdrive/w/as400/v4r4m0.java/cur/cmvc/java.pgm/jdb.java/src/com/ibm/db2/jdbc/app/

Now, both give the directory name of the soft link //f/kulack/l/jdb44
I need the full path in some scripts and tools.
Are there any alternative utils that can give me the full name?
Thanks!

dll version information from cygcheck -v -s
   56k 2000/12/03 c:\bin\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz21.0.dll" v0.0 ts=2000/11/20 17:53
   45k 2000/12/07 c:\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
                  "cygform5.dll" v0.0 ts=2000/12/7 0:41
   18k 2000/10/23 c:\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
                  "cyggdbm.dll" v0.0 ts=2000/10/22 21:26
   17k 2001/01/07 c:\bin\cyghistory4.dll - os=4.0 img=1.0 sys=4.0
                  "cyghistory4.dll" v0.0 ts=2001/1/6 22:34
   14k 2000/10/23 c:\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl.dll" v0.0 ts=2000/10/23 14:02
   81k 2000/12/05 c:\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=2000/11/25 19:43
   35k 2000/12/05 c:\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=2000/11/25 19:43
   45k 2000/10/22 c:\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
                  "cygjbig1.dll" v0.0 ts=2000/10/22 18:06
  119k 2000/10/23 c:\bin\cygjpeg6b.dll - os=4.0 img=1.0 sys=4.0
                  "cygjpeg6b.dll" v0.0 ts=2000/10/22 19:58
   26k 2000/12/07 c:\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu5.dll" v0.0 ts=2000/12/7 0:40
  159k 2000/12/07 c:\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++5.dll" v0.0 ts=2000/12/7 0:42
  225k 2000/12/07 c:\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses5.dll" v0.0 ts=2000/12/7 0:39
   15k 2000/12/07 c:\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel5.dll" v0.0 ts=2000/12/7 0:40
  162k 2000/10/23 c:\bin\cygpng2.dll - os=4.0 img=1.0 sys=4.0
                  "cygpng2.dll" v0.0 ts=2000/10/22 19:40
  108k 2001/01/07 c:\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0
                  "cygreadline4.dll" v0.0 ts=2001/1/6 22:34
  390k 2000/12/05 c:\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=2000/11/25 19:39
    5k 2000/12/05 c:\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 2000/12/05 c:\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=2000/11/25 19:39
  243k 2000/10/23 c:\bin\cygtiff3.dll - os=4.0 img=1.0 sys=4.0
                  "cygtiff3.dll" v0.0 ts=2000/10/22 20:14
  623k 2000/12/05 c:\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=2000/11/25 19:43
   41k 2000/11/20 c:\bin\cygXpm-noX4.dll - os=4.0 img=1.0 sys=4.0
                  "cygXpm-noX4.dll" v0.0 ts=2000/11/19 20:41
   45k 2000/11/20 c:\bin\cygXpm-X4.dll - os=4.0 img=1.0 sys=4.0
                  "cygXpm-X4.dll" v0.0 ts=2000/11/19 20:45
   49k 2000/10/23 c:\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
                  "cygz.dll" v0.0 ts=2000/10/22 19:22
  611k 2000/12/25 c:\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/12/25 11:39
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 7
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        dll malloc env: 28
        api major: 0
        api minor: 31
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        cygdrive flags: cygdrive flags
        cygdrive prefix: cygdrive prefix
        cygdrive default prefix:
        build date: Mon Dec 25 12:39:48 EST 2000
        shared id: cygwin1S3




--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Bob McGowan]

Based on the man page for 'pwd':

 "...That is, all components of the printed name will be actual
  directory names -- none will be symbolic links."

I'd say this is a bug.

As a quick hack, in the meantime, assuming you are using bash or ksh, run the following:

cygpath -u $(cygpath -w $PWD)

The first cygpath eliminates the symbolic link since they don't work as such in Windows, the second converts back to the expacted absolute path, sanse symbolic links.

Fred Kulack wrote:
> 
> I just upgraded from an older cygwin 1.1.x release to the current one.
> 
> It use to be that I could use /bin/pwd instead of the bash built-in
> If I wanted to get the full directory name of the cwd instead
> of the softlink name.
> 
> For example, in the following,
>  > ls -ld //f/kulack/l/jdb44
> lrw-r--r--   1 kulack   None           85 Sep 26 14:51 //f/kulack/l/jdb44
> ->
> //W/as400/v4r4m0.java/cur/cmvc/java.pgm/jdb.java/src/com/ibm/db2/jdbc/app/
> 
> pwd would give /cygdrive/f/
> /bin/pwd would give
> /cygdrive/w/as400/v4r4m0.java/cur/cmvc/java.pgm/jdb.java/src/com/ibm/db2/jdbc/app/
> 
> Now, both give the directory name of the soft link //f/kulack/l/jdb44
> I need the full path in some scripts and tools.
> Are there any alternative utils that can give me the full name?
> Thanks!
> 
> dll version information from cygcheck -v -s
>    56k 2000/12/03 c:\bin\cygbz21.0.dll - os=4.0 img=1.0 sys=4.0
>                   "cygbz21.0.dll" v0.0 ts=2000/11/20 17:53
>    45k 2000/12/07 c:\bin\cygform5.dll - os=4.0 img=1.0 sys=4.0
>                   "cygform5.dll" v0.0 ts=2000/12/7 0:41
>    18k 2000/10/23 c:\bin\cyggdbm.dll - os=4.0 img=1.0 sys=4.0
>                   "cyggdbm.dll" v0.0 ts=2000/10/22 21:26
>    17k 2001/01/07 c:\bin\cyghistory4.dll - os=4.0 img=1.0 sys=4.0
>                   "cyghistory4.dll" v0.0 ts=2001/1/6 22:34
>    14k 2000/10/23 c:\bin\cygintl.dll - os=4.0 img=1.0 sys=4.0
>                   "cygintl.dll" v0.0 ts=2000/10/23 14:02
>    81k 2000/12/05 c:\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
>                   "cygitcl30.dll" v0.0 ts=2000/11/25 19:43
>    35k 2000/12/05 c:\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
>                   "cygitk30.dll" v0.0 ts=2000/11/25 19:43
>    45k 2000/10/22 c:\bin\cygjbig1.dll - os=4.0 img=1.0 sys=4.0
>                   "cygjbig1.dll" v0.0 ts=2000/10/22 18:06
>   119k 2000/10/23 c:\bin\cygjpeg6b.dll - os=4.0 img=1.0 sys=4.0
>                   "cygjpeg6b.dll" v0.0 ts=2000/10/22 19:58
>    26k 2000/12/07 c:\bin\cygmenu5.dll - os=4.0 img=1.0 sys=4.0
>                   "cygmenu5.dll" v0.0 ts=2000/12/7 0:40
>   159k 2000/12/07 c:\bin\cygncurses++5.dll - os=4.0 img=1.0 sys=4.0
>                   "cygncurses++5.dll" v0.0 ts=2000/12/7 0:42
>   225k 2000/12/07 c:\bin\cygncurses5.dll - os=4.0 img=1.0 sys=4.0
>                   "cygncurses5.dll" v0.0 ts=2000/12/7 0:39
>    15k 2000/12/07 c:\bin\cygpanel5.dll - os=4.0 img=1.0 sys=4.0
>                   "cygpanel5.dll" v0.0 ts=2000/12/7 0:40
>   162k 2000/10/23 c:\bin\cygpng2.dll - os=4.0 img=1.0 sys=4.0
>                   "cygpng2.dll" v0.0 ts=2000/10/22 19:40
>   108k 2001/01/07 c:\bin\cygreadline4.dll - os=4.0 img=1.0 sys=4.0
>                   "cygreadline4.dll" v0.0 ts=2001/1/6 22:34
>   390k 2000/12/05 c:\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtcl80.dll" v0.0 ts=2000/11/25 19:39
>     5k 2000/12/05 c:\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
>    10k 2000/12/05 c:\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtclreg80.dll" v0.0 ts=2000/11/25 19:39
>   243k 2000/10/23 c:\bin\cygtiff3.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtiff3.dll" v0.0 ts=2000/10/22 20:14
>   623k 2000/12/05 c:\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
>                   "cygtk80.dll" v0.0 ts=2000/11/25 19:43
>    41k 2000/11/20 c:\bin\cygXpm-noX4.dll - os=4.0 img=1.0 sys=4.0
>                   "cygXpm-noX4.dll" v0.0 ts=2000/11/19 20:41
>    45k 2000/11/20 c:\bin\cygXpm-X4.dll - os=4.0 img=1.0 sys=4.0
>                   "cygXpm-X4.dll" v0.0 ts=2000/11/19 20:45
>    49k 2000/10/23 c:\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
>                   "cygz.dll" v0.0 ts=2000/10/22 19:22
>   611k 2000/12/25 c:\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
>                   "cygwin1.dll" v0.0 ts=2000/12/25 11:39
>     Cygwin DLL version info:
>         dll major: 1001
>         dll minor: 7
>         dll epoch: 19
>         dll bad signal mask: 19005
>         dll old termios: 5
>         dll malloc env: 28
>         api major: 0
>         api minor: 31
>         shared data: 3
>         dll identifier: cygwin1
>         mount registry: 2
>         cygnus registry name: Cygnus Solutions
>         cygwin registry name: Cygwin
>         program options name: Program Options
>         cygwin mount registry name: mounts v2
>         cygdrive flags: cygdrive flags
>         cygdrive prefix: cygdrive prefix
>         cygdrive default prefix:
>         build date: Mon Dec 25 12:39:48 EST 2000
>         shared id: cygwin1S3
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Christopher Faylor]

On Tue, Jan 16, 2001 at 02:56:23PM -0800, Bob McGowan wrote:
>Based on the man page for 'pwd':
>
> "...That is, all components of the printed name will be actual
>  directory names -- none will be symbolic links."
>
>I'd say this is a bug.

I'd say that this has been discussed in the mailing list several times
already.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Bob McGowan]

My apologies for failing to do an exhaustive archive search before responding.

Christopher Faylor wrote:
> 
> On Tue, Jan 16, 2001 at 02:56:23PM -0800, Bob McGowan wrote:
> >Based on the man page for 'pwd':
> >
> > "...That is, all components of the printed name will be actual
> >  directory names -- none will be symbolic links."
> >
> >I'd say this is a bug.
> 
> I'd say that this has been discussed in the mailing list several times
> already.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple

-- 
Bob McGowan
Staff Software Quality Engineer
VERITAS Software
rmcgowan@veritas.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Ehud Karni]

On Tue, 16 Jan 2001 14:56:23 -0800, Bob McGowan <rmcgowan@veritas.com> wrote:
> 
>  "...That is, all components of the printed name will be actual
>   directory names -- none will be symbolic links."
> 
> I'd say this is a bug.

Despite what Christopher Faylor <cgf@redhat.com> thinks, I'll say it
is a real bug with critical implications. If you want to check if
directories are the same, or in the same branch absolute paths must
be used. I have many scripts (all of them working on Linux and other
UNIX's) that use `/bin/pwd` to get the absolute path. If the current
situation is kept (i.e. `/bin/pwd` returning the path the shell used
to get to this directory, not the absolute one) then it is a big
immigration problem.

Mr. Bob McGowan suggest a solution that use Cygwin tools, namely:
    cygpath -u `cygpath -w `\`/bin/pwd\``
I checked it and it seems to work satisfactory, so why not change
the /bin/pwd to do it automaticly ?

Note. The shell pwd should continue to hold the symbolic path, so cd ..
      will get you to the directory you came from.

Ehud.


-- 
 @@@@@@ @@@ @@@@@@ @    @   Ehud Karni  Simon & Wiesel  Insurance agency
     @    @      @  @@  @   Tel: +972-3-6212-757    Fax: +972-3-6292-544
     @    @ @    @ @  @@    (USA)  Fax  and  voice  mail:  1-815-5509341
     @    @ @    @ @    @        Better     Safe     Than     Sorry
 http://www.simonwiesel.co.il    mailto:ehud@unix.simonwiesel.co.il

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Christopher Faylor]

On Wed, Jan 17, 2001 at 10:09:06PM +0200, Ehud Karni wrote:
>On Tue, 16 Jan 2001 14:56:23 -0800, Bob McGowan <rmcgowan@veritas.com> wrote:
>> 
>>  "...That is, all components of the printed name will be actual
>>   directory names -- none will be symbolic links."
>> 
>> I'd say this is a bug.
>
>Despite what Christopher Faylor <cgf@redhat.com> thinks, I'll say it
>is a real bug with critical implications.

Huh?  I never said it wasn't a bug.  Quite the contrary.

I suggested that people read the email archives.  Look for "pwd symlink".

>If you want to check if directories are the same, or in the same branch
>absolute paths must be used.  I have many scripts (all of them working
>on Linux and other UNIX's) that use `/bin/pwd` to get the absolute
>path.  If the current situation is kept (i.e.  `/bin/pwd` returning the
>path the shell used to get to this directory, not the absolute one)
>then it is a big immigration problem.

I have no idea what an "immigration problem" is but you're welcome, as
always to submit a patch.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Christopher Faylor]

On Wed, Jan 17, 2001 at 03:43:18PM -0500, Christopher Faylor wrote:
>On Wed, Jan 17, 2001 at 10:09:06PM +0200, Ehud Karni wrote:
>>On Tue, 16 Jan 2001 14:56:23 -0800, Bob McGowan <rmcgowan@veritas.com> wrote:
>>> 
>>>  "...That is, all components of the printed name will be actual
>>>   directory names -- none will be symbolic links."
>>> 
>>> I'd say this is a bug.
>>
>>Despite what Christopher Faylor <cgf@redhat.com> thinks, I'll say it
>>is a real bug with critical implications.
>
>Huh?  I never said it wasn't a bug.  Quite the contrary.
>
>I suggested that people read the email archives.  Look for "pwd symlink".

I've checked in a fix for this.  It will be in cygwin 1.1.8.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Christopher Faylor]

On Thu, Jan 18, 2001 at 05:33:25PM +0200, Ehud Karni wrote:
>On Thu, 18 Jan 2001 09:12:12 +0100, Bernard Dautrevaux <Dautrevaux@microprocess.com> wrote:
>>>I have no idea what an "immigration problem" is but you're welcome, as
>>>always to submit a patch.
>>
>>I think Ehud wanted to say a "migration problem", and that's exactly
>>what I'm afraid of for some of my scripts I have to migrate to cygwin
>>and probably why some complicated ones are broken there that I do not
>>had time to investigate ;-(
>
>You got my intention right (I'm sorry for my English mistakes).  I
>wonder why cgf did not get it, may be he does not have to do such
>chores ?

I am sorry that I did not equate immigration with migration.  I was not
casting aspersions on your command of English.  I simply did not understand
what you were talking about.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: /bin/pwd versus built-in pwd

[Bernard Dautrevaux]

> -----Original Message-----
> From: Ehud Karni [ mailto:ehud@unix.simonwiesel.co.il ]
> Sent: Thursday, January 18, 2001 4:33 PM
> To: Dautrevaux@microprocess.com
> Cc: cygwin@sources.redhat.com
> Subject: Re: /bin/pwd versus built-in pwd
> 
> 
> On Thu, 18 Jan 2001 09:12:12 +0100, Bernard Dautrevaux 
> <Dautrevaux@microprocess.com> wrote:
> > > 
> > > I have no idea what an "immigration problem" is but 
> you're welcome, as
> > > always to submit a patch.
> > 
> > I think Ehud wanted to say a "migration problem", and 
> that's exactly what
> > I'm afraid of for some of my scripts I have to migrate to cygwin and
> > probably why some complicated ones are broken there that I 
> do not had time
> > to investigate ;-(
> 
> You got my intention right (I'm sorry for my English mistakes).
> I wonder why cgf did not get it, may be he does not have to do such
> chores ?

More probably it's because English is not my native language; I've already
noticed that non-native english people understand best the erroneous english
of other non-english people. 

And BTW I've also noticed I have more difficulties to understand erroneous
french sentences from foreigners :-) 

I think its just that you are usually so used to your native language and to
trust others to speak it correctly that you are less fault-tolerant; OTOH
for foreign languages you're usually used to "fuzzy-logic" translations :-)

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Ehud Karni]

On Thu, 18 Jan 2001 09:12:12 +0100, Bernard Dautrevaux <Dautrevaux@microprocess.com> wrote:
> > 
> > I have no idea what an "immigration problem" is but you're welcome, as
> > always to submit a patch.
> 
> I think Ehud wanted to say a "migration problem", and that's exactly what
> I'm afraid of for some of my scripts I have to migrate to cygwin and
> probably why some complicated ones are broken there that I do not had time
> to investigate ;-(

You got my intention right (I'm sorry for my English mistakes).
I wonder why cgf did not get it, may be he does not have to do such
chores ?
As for the patch, I'll try to look into that (my solution may be the
easiest one, not the best one).

Ehud.


-- 
 @@@@@@ @@@ @@@@@@ @    @   Ehud Karni  Simon & Wiesel  Insurance agency
     @    @      @  @@  @   Tel: +972-3-6212-757    Fax: +972-3-6292-544
     @    @ @    @ @  @@    (USA)  Fax  and  voice  mail:  1-815-5509341
     @    @ @    @ @    @        Better     Safe     Than     Sorry
 http://www.simonwiesel.co.il    mailto:ehud@unix.simonwiesel.co.il

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: /bin/pwd versus built-in pwd

[Bernard Dautrevaux]

> -----Original Message-----
> From: Christopher Faylor [ mailto:cgf@redhat.com ]
> Sent: Wednesday, January 17, 2001 9:43 PM
> To: cygwin@cygwin.com
> Subject: Re: /bin/pwd versus built-in pwd
> 
> 
> On Wed, Jan 17, 2001 at 10:09:06PM +0200, Ehud Karni wrote:
> >On Tue, 16 Jan 2001 14:56:23 -0800, Bob McGowan 
> <rmcgowan@veritas.com> wrote:
> >> 
> >>  "...That is, all components of the printed name will be actual
> >>   directory names -- none will be symbolic links."
> >> 
> >> I'd say this is a bug.
> >
> >Despite what Christopher Faylor <cgf@redhat.com> thinks, I'll say it
> >is a real bug with critical implications.
> 
> Huh?  I never said it wasn't a bug.  Quite the contrary.
> 
> I suggested that people read the email archives.  Look for 
> "pwd symlink".

Looked at the archive; seems like to fix a bug in find, we've add a bug in
getcwd()? :-)

> 
> >If you want to check if directories are the same, or in the 
> same branch
> >absolute paths must be used.  I have many scripts (all of 
> them working
> >on Linux and other UNIX's) that use `/bin/pwd` to get the absolute
> >path.  If the current situation is kept (i.e.  `/bin/pwd` 
> returning the
> >path the shell used to get to this directory, not the absolute one)
> >then it is a big immigration problem.
> 
> I have no idea what an "immigration problem" is but you're welcome, as
> always to submit a patch.

I think Ehud wanted to say a "migration problem", and that's exactly what
I'm afraid of for some of my scripts I have to migrate to cygwin and
probably why some complicated ones are broken there that I do not had time
to investigate ;-(

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: /bin/pwd versus built-in pwd

[Fred Kulack]

Sorry, I know you get sick of seeing the same thing
all the time (so do I, I just don't read every single post, nor
have responsibilities here so it bothers me less).

Anyway, my main question was
> Are there any alternative utils that can give me the full name?

Bob gave me the workaround to this.
Thanks Bob!


Excuse that I felt I need because I was 'slapped down'.... 8-)

I did of course search the archives with several combinations
of stuff. i.e.'pwd', 'pwd symbolic links', 'pwd full directory symbolic
link', etc...

Its still easy to miss things in there. I went back and looked
again after your post, and finally found one line from Corinna
that didn't show up in my searches above, but was present in the
discussion thread that indicated it was a bug.
http://sources.redhat.com/ml/cygwin/2000-10/msg00906.html



On Tue, Jan 16, 2001 at 02:56:23PM -0800, Bob McGowan wrote:
>Based on the man page for 'pwd':
>
> "...That is, all components of the printed name will be actual
>  directory names -- none will be symbolic links."
>
>I'd say this is a bug.

I'd say that this has been discussed in the mailing list several times
already.

cgf



--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple