[lug] strange filesystem behavior

[Michael Hirsch]

Thanks Jeffrey and Davide.

I guess it makes sense--I'm not sure why I never noticed it before.  I
still have one file path that isn't resolving correctly, but I think
it is a slightly different issue.

Michael

On Wed, Apr 13, 2016 at 1:57 PM, Jeffrey S. Haemer
<jeffrey.haemer at gmail.com> wrote:
> Michael,
>
> It's because "ls" is a program, but "cd" is a builtin.  From the bash man
> page:
>
> cd [-L|[-P [-e]] [-@]] [dir]
>               Change  the  current  directory  to dir.  if dir is not
> supplied, the value of the HOME shell variable is the default.  Any
> additional
>               arguments following dir are ignored.  The variable CDPATH
> defines the search path for the directory  containing  dir:  each  directory
>               name  in  CDPATH  is  searched for dir.  Alternative directory
> names in CDPATH are separated by a colon (:).  A null directory name in
>               CDPATH is the same as the current directory, i.e., ``.''.  If
> dir begins with a slash (/), then CDPATH is  not  used.  The  -P  option
>               causes  cd to use the physical directory structure by
> resolving symbolic links while traversing dir and before processing
> instances of
>               .. in dir (see also the -P option to the set builtin command);
> the -L option forces symbolic links to be  followed  by  resolving  the
>               link  after  processing  instances  of .. in dir.  If ..
> appears in dir, it is processed by removing the immediately previous
> pathname
>               component from dir, back to a slash or the beginning of dir.
> If the -e option is supplied with -P, and the current working  directory
>               cannot be successfully determined after a successful directory
> change, cd will return an unsuccessful status.  On systems that support
>               it, the -@ option presents the extended attributes associated
> with a file as a directory.  An argument of - is  converted  to  $OLDPWD
>               before  the  directory change is attempted.  If a non-empty
> directory name from CDPATH is used, or if - is the first argument, and the
>               directory change is successful, the absolute pathname of the
> new working directory is written to  the  standard  output.   The  return
>               value is true if the directory was successfully changed; false
> otherwise.
>
>
> Moreover
>
> set -P      If set, the shell does not resolve symbolic links when executing
> commands such as cd that change the  current  working  direc‐
>                 tory.   It uses the physical directory structure instead.
> By default, bash follows the logical chain of directories when per‐
>                 forming commands which change the current directory.
>
> HTH!
>
> On Wed, Apr 13, 2016 at 1:28 PM, Davide Del Vento
> <davide.del.vento at gmail.com> wrote:
>>
>> The point with syslinked directories is that if you have
>>
>> /foo/bar/baz
>>
>> which is a syslink to
>>
>> /whatever/the/heck
>>
>> and you cd into /foo/bar/baz, then when you do "cd .." or "ls .." in one
>> case you go to /foo/bar/ in the other you go /whatever/the/ (forgot
>> what-is-what)
>>
>> I noticed it pretty early when I encountered syslink'ed directories years
>> ago, and never investigated further, just learnt to live with it.
>>
>> On Wed, Apr 13, 2016 at 1:17 PM, Michael Hirsch <mdhirsch at gmail.com>
>> wrote:
>>>
>>> Can anyone explain this?  The owners of this system use a lot of
>>> symlinks to play weird games with their files.  For instance, in the
>>> directory used below, /var/tmp/jobsched/jaws/conf the last entry,
>>> conf, is actually a symlink into another filesystem entirely.  But I
>>> still don't understand how this is possible.
>>>
>>> Consider this:
>>> bash-4.1$ pwd
>>> /var/tmp/jobsched/jaws/conf
>>> bash-4.1$ ls ../../../..
>>> autosys_api  common  daemon         jaws.sh            jboss  log
>>> sbin     sdk
>>> batch        config  import_export  jaws.sh.vmoptions  lib    README
>>> scripts  tools
>>> bash-4.1$ cd ../../../..
>>> bash-4.1$ ls
>>> account  cvs    etscfg  lib    lost+found  mqm.client  phd        run
>>>    VRTSat_lhc  yp
>>> adm      db     ftp     local  lum         nis         preserve
>>> spool   VRTSvcs     zapplets
>>> cache    db2    games   lock   mail        openv       prodperim  tmp
>>> vx
>>> crash    empty  gdm     log    mqm         opt         redhat     VRTSat
>>> vxvm
>>>
>>> So when I "ls ../../../.." ls sees a bunch of file, starting with
>>> "autosys_api" and "common".  But if I cd to that directory ls sees a
>>> completely different set of files.
>>>
>>> I didn't think that symlinks and filesystems worked like this.  I
>>> expected to see the same files in the two "ls" commands.
>>>
>>> What is making this happen?  What am I missing.
>>>
>>> Thanks,
>>>
>>> Michael
>>> _______________________________________________
>>> Web Page:  http://lug.boulder.co.us
>>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>>
>>
>>
>> _______________________________________________
>> Web Page:  http://lug.boulder.co.us
>> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
>> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety
>
>
>
>
> --
> Jeffrey Haemer <jeffrey.haemer at gmail.com>
> 720-837-8908 [cell], http://seejeffrun.blogspot.com [blog],
> http://www.youtube.com/user/goyishekop [vlog]
> פרייהייט? דאס איז יאַנג דינען וואָרט.
>
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: irc.hackingsociety.org port=6667 channel=#hackingsociety