Передача по каналу путей с различными типами кавычек для замены наклонной черты

Не использовать echo. Проблема с echo есть ли существует слишком много версий, и каждый обрабатывает обратные косые черты немного по-другому. Ваш очевидно интерпретирует обратные косые черты в Вашей исходной строке. Если Вы просто сделали

# first attempt
echo '\\path\to\file\'

Я подозреваю, что Вы видели бы

\path   o
         ile\

Так же во всех Ваших других попытках проблема с Вашим использованием echo и взаимодействия между echo и заключение в кавычки оболочки и обратные косые черты, а не со второй частью канала ( sed или tr).

Решение состоит в том, чтобы использовать printf вместо этого - его поведение является намного более последовательным и портативным, так как оно указано POSIX.

printf '\\\\path\\to\\file\\\n'

получает Вас

\\path\to\file\

Можно просто использовать POSIX heredoc сделать это:

% sed -e 's@\\@/@g' -e 's@\(.\):\(.*\)@/drive/\1\2@' <<'_EOF_' 
> c:\some\stupid\windows\place
> _EOF_
/drive/c/some/stupid/windows/place

Мой ответ на Является там способом добраться, фактические неинтерпретируемые аргументы оболочки в функции описывает это более подробно включая как к динамично read это в переменную оболочки через замену команды при необходимости и передачу это как аргумент функции оболочки.

В моем ответе на Заключение в кавычки в ssh $host$FOO и ssh $host “sudo su пользователь-c $FOO” вводят конструкции, которые я предлагаю, возможно, отличающийся, и, как я полагаю, больше простых средств решения проблемы, которой иначе превосходно ответили.

Править: Я сожалею, но я первоначально пропустил Ваш запрос на "объяснение почему ни одна из [Ваших] попыток [при заключении в кавычки обратных косых черт, как проиллюстрировано в Вашем вопросе] выше обработанного":

Прием к пониманию ответа, в то время как не на самом деле очень таинственный самостоятельно, справедлив, к сожалению, довольно неинтуитивный. Основной барьер, с которым мы обычно встречаемся вдоль этих строк, или, по крайней мере, что я делаю, то, что shell наш интерфейс по умолчанию к компьютеру. По сути, я думаю, что может иногда быть трудно помнить, что это - просто программа; это - просто приложение как любой другой.

Могло бы быть немного легче видеть через него, если Вы передвигаете названия вещей немного; не называйте его"shell", но попытка называя его вместо этого"command interpreter"(хотя shell был бы, вероятно, прекрасен также, если бы слово имело тенденцию наследовать меньше jargonal коннотации, и ее значение основы выделилось немного лучше).

Я нахожу легче более правильно приписать меньше управления shell чем я мог бы иначе сделать, когда это становится, вместо этого, просто мой interpreter. Для меня также таким образом легче помнить, что то, когда это включило его, не интерпретирует только меня, но также и, верное для его цели и по его самому характеру, это делает попытку посреднику любого разговора, к которому это тайно; если дано шанс, shell интерпретирует переданный тот данных других приложений к другому, должен ли он или нет.

То, в чем я являюсь ведущим, то, что command interpreter естественно интерпретирует по умолчанию всю информацию, переданную ему на ее собственный язык, но ее язык не обязательно больше корректен самостоятельно, чем язык какого-либо другого приложения. Конечно, выгодно для других приложений говорить хорошо на языке command interpreter, целесообразно избавляя их от необходимости интерпретировать Вас самих, но у них есть столько же право попробовать, как оно делает, поскольку они - все просто компьютерные программы в конце.

При усложнении ситуацию для его родственных приложений нет никакого единственного права или неправильного способа интерпретировать команды. Самым близким для исправления, где Unix затронут (и поэтому возможно вообще) является, вероятно, стандарт POSIX, но он, конечно, оставляет некоторое пространство для маневра для интерпретации интерпретации (который был забавой сказать, и, как я надеюсь, должен, вероятно, проиллюстрировать мой тезис). Результатом является своего рода цифровой аналог языка многим диалектам человеческого аналогового языка (также забава).

(Большая часть вышеупомянутого является просто краткой информацией и является, вероятно, по крайней мере, немного ненужной, чтобы полностью понять следующее, но я надеюсь, что оно поможет.)

Когда мы передаем команду shell это выполняет итерации по списку правил, которые это программируется для рассмотрения в определенном порядке интерпретировать нашу команду перед проведением ее интерпретации нашей команды, поскольку это интерпретировало, мы предназначаем, чтобы это было должно. Наши основные средства влияния, которое управляет и в том, какой порядок оно рассматривает ими (кроме самой команды, конечно) являются различными типами shell quotes, среди которого обычно включается, поскольку Вы нашли, \ символ обратной косой черты.

Другие приложения имеют почти столько же причины и так же право применить их собственные интерпретирующие наборы правила, но мало вероятны иметь шанс прежде сначала shell делает, и таким образом, обычно их правила будут смоделированы после тех shell. Это может быть сложно, когда они принимают ту же механику заключения в кавычки как shell, потому что это оставляет на нас бремя (hehe) к \'"quote our quotes"\'. Эта сложность может быть разочаровывающе увеличена когда shell и наше целевое приложение отличается только очень мало по заключению в кавычки синтаксиса, и мы должны косвенно обратиться к одному через другой с помощью точно утомительной инструкции так, чтобы ничто не было потеряно в переводе.

Мое предпочтительное средство обработки таких ситуаций, как я продемонстрировал в своем блоке кода выше, состоит в том, чтобы только непосредственно сообщить shell где засунуть его, если можно так выразиться, и что это должно просто в значительной степени проигнорировать все от <<'HERE' на том, потому что я думаю, что могу обработать один только этот разговор, спасибо очень много, и я, несомненно, сообщу ему \nHERE\n когда это должно начать обращать внимание снова.

[1120833] В [1121199] bash[1121200] первая попытка работает как шарм. Это зависит от того, что такое [1121201]echo[1121202] и какая версия у вас запущена. Например, [1121203]echo[1121204] является встроенным басом и переопределяет [1121205]/бин/эхо[1121206] или [1121207]/usr/бин/эхо[1121208]. Проверьте [1121209]man bash[1121210] и [1121211]info zsh[1121212], чтобы сравнить, какие опции они принимают и каковы значения по умолчанию. На самом деле вы хотите заставить [1121213]echo -E[1121214] отключить интерпретацию экранирующих последовательностей. По умолчанию оно используется для [1121215]bash[1121216], но, очевидно, не в [1121217]zsh[1121218]. Вы также можете отключить эту конкретную сборку (я не использую [1121219]zsh[1121220], поэтому не знаю как), или использовать наиболее распространенный способ обработки: явно вызывать [1121221]echo[1121222] как [1121223]/bin/echo[1121224]. Edit: Конечно, вам нужны одинарные кавычки, иначе оболочка интерпретирует экранирующие последовательности до того, как [1121225]echo[1121226] даже получит шанс.[1120838].