Сообщение Re[8]: Git wtf?.. от 12.02.2016 8:05
Изменено 12.02.2016 8:07 netch80
Здравствуйте, woah, Вы писали:
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
У Git нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."
Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).
2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.
3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
У Git нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."
Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).
2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.
3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
Re[8]: Git wtf?..
Здравствуйте, woah, Вы писали:
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."
Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).
2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.
3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
(*) виндовые адаптации я не учитываю — вполне возможно, их авторы просто не осилили продраться сквозь вышеописанные грабли, и если это не целенаправленная разработка под Windows, не считаю возможным упрекать их в этом.
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."
Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).
2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.
3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
(*) виндовые адаптации я не учитываю — вполне возможно, их авторы просто не осилили продраться сквозь вышеописанные грабли, и если это не целенаправленная разработка под Windows, не считаю возможным упрекать их в этом.