башепроблемы

Кстати да. На zsh такое не проявляется.

шо интересно

dk@stout://$ cd bin
dk@stout://bin$ pwd
//bin

У мну тоже самое: [code] [dada@localhost bin]$ cd //usr/local/ [dada@localhost local]$ pwd //usr/local [/code]

да. есть такая особенность у bash'а. Но это не баг, т.к. запись // вполне корректна.

А почему ? Расскажи.

[dada@localhost local]$ cd ///
[dada@localhost /]$ pwd
/

Here:

A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.

Боян

http://dbaspot.com/shell/407921-how-come-also-root-bash.html

Спасибо.

schizoid

A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash.

спасибо конечно, вот только непонятно, что там такого неразрешимого?

Заметил ещё в 2004, кажется, году. С тех пор кому рассказывал - все отбрехивались в стиле «ой, да, как с таким багом жить-то?!11» :)

Тред прочитал, суть так и не уловил.

Я вот всё читаю, по ссылке, которую schizoid дал.
Там вроде написано, что это нормально. Но причины не названы.

Скопипастил из доки целиком абзац по путям просто

спасибо конечно, вот только непонятно, что там такого неразрешимого?

Ты про это?

A null pathname shall not be successfully resolved.

PATHNAME=«» - плохой, негодный путь.

Причина - путь //blah/blah может считаться особого вида путём. Например, путь к файлу на сетевой шаре. От фантазии реализатора зависит.

Такой себе scrolllock-аналог для путей.

да спасибо, про file:/// я как-то и позабыл..

Если так, то первый кусок вида «[^/]+» должен обрабатываться как имя хоста, чего не наблюдаем. Недостаточно по-другому интерпретировать //, не?

первый кусок вида «[^/]+» должен обрабатываться как имя хоста

Не должен. Может. Если реализатор захочет. Зарезервированное поведение, на случай желаний от левой пятки. Поэтому не рекомендуется использовать двойные слеши в начале пути при программной генерации путей, во избежание.

В современных башах, AFAIK, делает в действительности следующее: абсолютно ничего. А ksh вообще любые повторения слешей приводит к одному.

а теперь, быстро, решительно, объяснили, приём тут bash:

$ gcc -xc -<<<'#include <sys/types.h>

#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>
int main(){ printf(«fd = %d\n», open(«////tmp////111», O_CREAT)); }'; ./a.out

fd = 3

Это стандарт идиот, там не объясняют причин.

Идиот. file:// это протокол, третьй слеш - начало абсолютного пути. ЧИТАТЬ МАТЧАСТЬ быстро и решительно

POSIX PATH а не шел

anonymous

Идиот. file:// это протокол

я в курсе. И да, пруфлинк на матчасть, быстро и решительно.

вы, нубы, ещё и забанены в гугле? http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_0...

A character string that is used to identify a file. In the context of IEEE Std 1003.1-2001, a pathname consists of, at most, {PATH_MAX} bytes, including the terminating null byte. It has an optional beginning slash, followed by zero or more filenames separated by slashes. A pathname may optionally contain one or more trailing slashes. Multiple successive slashes are considered to be the same as one slash.

anonymous

вы, нубы, ещё и забанены в гугле?

мы, нубы, ещё и найти там не можем протокол file://