LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 05-08-2012, 04:50 PM   #1
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
/.../ in directory path


Building 'libproxy' and running 'make install' (Makefiles are generated by 'cmake') I've noticed lines like this:

Code:
-- Installing: /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../../lib/site_perl/5.14.2/i686-linux-thread-multi/Net/Libproxy.pm
- pay attention to "/.../".

/bin/sh accepts such paths, for example:

Code:
sergei@amdam2:~/junk> cd /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../../lib/site_perl/5.14.2/i686-linux-thread-multi/Net/
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/lib/site_perl/5.14.2/i686-linux-thread-multi/Net> pwd
/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/lib/site_perl/5.14.2/i686-linux-thread-multi/Net
From the above it looks like

Code:
/.../../
is equivalent to

Code:
/
.

Could someone please enlighten me where and and what to read on "/.../" - I don't remember seeing it before.
 
Old 05-08-2012, 04:59 PM   #2
Kustom42
Senior Member
 
Registered: Mar 2012
Distribution: Red Hat
Posts: 1,604

Rep: Reputation: 415Reputation: 415Reputation: 415Reputation: 415Reputation: 415
That does not work for me and I have never seen or heard of it during my red hat admin days. I tried several test shell scripts and none worked.
 
Old 05-08-2012, 05:02 PM   #3
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Original Poster
Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
Quote:
Originally Posted by Kustom42 View Post
That does not work for me and I have never seen or heard of it during my red hat admin days. I tried several test shell scripts and none worked.
FWIW, I am seeing this on my SUSE-11.1 box.
 
Old 05-08-2012, 05:19 PM   #4
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Original Poster
Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
Well, RTFMing (man 1p cd) I see:

Code:
       8. The curpath value shall then be converted to canonical form as follows, considering each component from beginning to end, in sequence:
...
           b. For each dot-dot component, if there is a preceding component and it is neither root nor dot-dot, the preceding component, all slashes separating  the  pre-
               ceding component from dot-dot, dot-dot and all slashes separating dot-dot from the following component shall be deleted.
- does it explain the behavior I observe ?
 
Old 05-08-2012, 05:38 PM   #5
Kustom42
Senior Member
 
Registered: Mar 2012
Distribution: Red Hat
Posts: 1,604

Rep: Reputation: 415Reputation: 415Reputation: 415Reputation: 415Reputation: 415
I do not see that text in my bash builtins man page. Where did you locate that information?
 
Old 05-08-2012, 05:40 PM   #6
Kustom42
Senior Member
 
Registered: Mar 2012
Distribution: Red Hat
Posts: 1,604

Rep: Reputation: 415Reputation: 415Reputation: 415Reputation: 415Reputation: 415
I missed your suse response. That would probably indicate a difference between the two families of Linux. Your excerpt does make sense; if it is from the man page for cd on your system then I would say there is your answer.
 
Old 05-08-2012, 09:55 PM   #7
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
I think /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../ must exist for that to work. Unless SuSE applies some very unsafe patches to its path resolution code.

In particular, cd /foo/.../../bar/ does not work on any of my systems (Debian and RHEL variants, no SuSE), when /foo/bar/ exists but /foo/.../ does not. (The cd(1) man page does have the same dot-dot handling description.)

Last edited by Nominal Animal; 05-08-2012 at 09:58 PM.
 
Old 05-09-2012, 03:00 AM   #8
Sergei Steshenko
Senior Member
 
Registered: May 2005
Posts: 4,481

Original Poster
Rep: Reputation: 454Reputation: 454Reputation: 454Reputation: 454Reputation: 454
Quote:
Originally Posted by Nominal Animal View Post
I think /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../ must exist for that to work. Unless SuSE applies some very unsafe patches to its path resolution code.

In particular, cd /foo/.../../bar/ does not work on any of my systems (Debian and RHEL variants, no SuSE), when /foo/bar/ exists but /foo/.../ does not. (The cd(1) man page does have the same dot-dot handling description.)
It apparently exists and shows up as a regular directory:


Code:
sergei@amdam2:~/junk> cd /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> pwd
/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> ls
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> ls -A
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> cd
sergei@amdam2:~> cd /mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/.../
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> pwd
/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> ls -a
.  ..
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7/...> cd ..
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7> ls -F
___ALREADY_BUILT___.libproxy-0.4.7  bin/  binsh/  include/  lib/  libproxy-0.4.7.dirs_with_so_or_a_files.prl  libproxy-0.4.7.PATH.txt  libproxy.py  share/
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7> ls -Fa
./  ../  .../  ___ALREADY_BUILT___.libproxy-0.4.7  bin/  binsh/  include/  lib/  libproxy-0.4.7.dirs_with_so_or_a_files.prl  libproxy-0.4.7.PATH.txt  libproxy.py  share/
sergei@amdam2:/mnt/sdb8/sergei/AFSWD_debug/20120424/libproxy-0.4.7>
.

Maybe it is created as a temporary hidden directory by 'make install', and later on files are moved from there to their final destinations ?

I yet to have to parse the quoted manpage piece.

Last edited by Sergei Steshenko; 05-09-2012 at 05:19 AM.
 
Old 05-09-2012, 04:57 AM   #9
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
Quote:
Originally Posted by Sergei Steshenko View Post
Maybe it is created as a temporary hidden directory by 'make install', and later on files are moved from there to their final destinations ?
I think you are spot on. Usually, the temporary install directory is something like .libs , or .$builddir . Since this package is configured via cmake .. (I think), perhaps the temporary install directory name is constructed by prepending a dot to the parameter to configuring cmake, yielding ... simply by accident?!

Quote:
Originally Posted by Sergei Steshenko View Post
I yet to have to parse the quoted manpage piece.
In any case, the quoted passage is incorrect in practice.

Path resolution does not simply apply s|/\+\([^/]+\)/\+\.\./\+|/|g (repeatedly) to the path to remove /../ components, because that would be a security risk.

In most cases, a path is assumed to be valid component-wise. That is, you should be able to trim a component off the end of the path, and end up in an existing, accessible directory, if the full path was accessible. If you allow nonexistent path components, that no longer applies.

The same rule applies when a component exists, but is inaccessible. Consider path /foo/bar/../baz/ where /foo/baz/ exists and is accessible, and /foo/bar/ also exists but is inaccessible. Because paths should be valid component-wise in practice, the original path should NOT be accessible.

I suspect this behaviour is implicitly standardized in POSIX; perhaps there is a passage that states that all components in a path must be accessible for the complete path to be accessible?

Unfortunately I'm too lazy to check. I first became aware of this almost a decade ago, when I was researching why Apache does so many directory lookups. (Partly due to this, partly due to .htaccess files and <Directory> directives.)
 
Old 05-10-2012, 06:14 AM   #10
AnanthaP
Member
 
Registered: Jul 2004
Location: Chennai, India
Posts: 952

Rep: Reputation: 217Reputation: 217Reputation: 217
AFAIR it was an old novell netware feature.
 
Old 05-10-2012, 06:40 AM   #11
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
@AnanthaP: You mean old Novell Netware accepted paths like foo\bar\..\baz as long as foo\baz existed even if foo\bar did not?

As it turns out, POSIX.1-2008 (IEEE Std 1003.1™-2008) realpath() function (which applications are supposed to but not required to use to canonicalize a path before doing any manipulations to it), does specify the explicit behaviour that I described earlier -- that foo/bar/../baz is accessible only if both foo/bar and foo/baz exist and are accessible:
Quote:
The realpath() function shall fail if: Read or search permission was denied for a component of file_name [, or a] component of the path prefix is not a directory
In Linux, the kernel applies the same rule to all path resolution.
 
Old 05-10-2012, 11:11 AM   #12
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
".." is a hard link to the parent directory, except in "/", which has ".." as a hard link to ".". While this might only be "simulated", processing the text of the pathname won't always be accurate. Suppose you had "/home/you/dir" -> "/". If you only went by the text, cd ~/dir/../home wouldn't work unless there was a "/home/you/home". Processing the text would also result in different behavior within C programs since presumably there isn't a kernel option to treat "..." specially. Also, I really wonder why there's a manpage for cd and why it could be different on another distro, since as far as I know cd can only work as a built-in (short of some procfs magic that I don't know about.) The manpage I have for cd is for a tcl built-in.
Kevin Barry
 
Old 05-10-2012, 11:39 AM   #13
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
Quote:
Originally Posted by ta0kira View Post
".." is a hard link to the parent directory, except in "/", which has ".." as a hard link to ".". While this might only be "simulated", processing the text of the pathname won't always be accurate.
If you process each component separately, building upon the path component by component, it will be logically correct.

Quote:
Originally Posted by ta0kira View Post
Suppose you had "/home/you/dir" -> "/". If you only went by the text, cd ~/dir/../home wouldn't work unless there was a "/home/you/home".
I don't understand that statement. POSIX.1-2008 realpath() and the Linux kernel path resolution handles that just fine by the text. ~/dir/../home is expanded by the shell to /home/you/dir/../home (~ is not special to the kernel nor realpath()), which is resolved in five steps:
  1. /home
  2. /home/you
  3. /home/you/dir
    At this point, the resolved location is at / for both realpath() and the Linux kernel.
  4. /home/you/dir/..
    The parent directory always exists, even at root. The resolved location stays at root for both realpath() and the Linux kernel.
  5. /home/you/dir/../home
    Since the resolved location has a subdirectory home (as resolved already in the first step), this resolves to the exact same location as the first step.

I cannot find any contradiction between this behaviour and the POSIX.1-2008 text I quoted!

Quote:
Originally Posted by ta0kira View Post
Processing the text would also result in different behavior within C programs since presumably there isn't a kernel option to treat "..." specially.
What? Like I said, every path component must exist and be accessible, for the path to exist and be accessible. This applies to both the Linux kernel, and POSIX.1-2008 realpath() function. (I have not bothered to check whether this is required by POSIX.1-2008 for all filesystems.)

Quote:
Originally Posted by ta0kira View Post
Also, I really wonder why there's a manpage for cd and why it could be different on another distro, since as far as I know cd can only work as a built-in (short of some procfs magic that I don't know about.) The manpage I have for cd is for a tcl built-in.
Because the cd utility is in the POSIX standard. Regardless of how it is implemented, its functionality should be the same for users. This functionality is what the man page describes. (And as such, it is part of the POSIX man pages.)
 
Old 05-10-2012, 01:46 PM   #14
ta0kira
Senior Member
 
Registered: Sep 2004
Distribution: FreeBSD 9.1, Kubuntu 12.10
Posts: 3,078

Rep: Reputation: Disabled
(nevermind)
 
Old 05-10-2012, 03:10 PM   #15
Nominal Animal
Senior Member
 
Registered: Dec 2010
Location: Finland
Distribution: Xubuntu, CentOS, LFS
Posts: 1,723
Blog Entries: 3

Rep: Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948Reputation: 948
Quote:
Originally Posted by ta0kira View Post
(nevermind)
I'm genuinely puzzled. If I offended you or anyone else, I apologize; it was not my intention. I only wanted to clarify the issues.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
How to remove directory from $PATH infraredgirl Linux - Newbie 13 03-19-2011 03:22 AM
adding directory to the path threaderslash Programming 1 04-02-2009 12:45 AM
Find a file path and directory path ak.lokesh Linux - Newbie 3 02-19-2009 12:37 PM
add a directory to PATH HarryBoy Linux - Newbie 5 05-02-2008 12:39 PM
How to rsynce the actual directory path instead of just the directory at the end of Niceman2005 Linux - General 5 04-08-2005 07:58 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 08:46 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration