Поддерживаю, терминологию специфическую не стоит переводить, а вот пояснение в глоссарии дать неплохо бы.

ну всяко лучше, чем "скрытые файлы", как тут Fat-Zer советует. Это же не для кю написано, у которых палец к мышке прирос 

я-бы написал, если мне доступ дадут…

как слово "труба" связана со словом "конвейер"? В русском языке — никак.

в том-то и дело, что конвейер это

command1 | command2

а pipe это способ передачи информации, в частном случае — в конвейере. Но не обязательно в нём. В общем случае pipe это просто файл(специальный конечно).

DESCRIPTION
       Pipes  and  FIFOs (also known as named pipes) provide a unidirectional interprocess communication channel.  A pipe has a
       read end and a write end.  Data written to the write end of a pipe can be read from the read end of the pipe.

       A pipe is created using pipe(2), which creates a new pipe and returns two file descriptors, one referring  to  the  read
       end  of  the  pipe,  the  other referring to the write end.  Pipes can be used to create a communication channel between
       related processes; see pipe(2) for an example.

       A FIFO (short for First In First Out) has a name within the filesystem (created using mkfifo(3)), and  is  opened  using
       open(2).   Any  process  may  open  a  FIFO,  assuming  the file permissions allow it.  The read end is opened using the
       O_RDONLY flag; the write end is opened using the O_WRONLY flag.  See fifo(7) for further details.  Note: although  FIFOs
       have a pathname in the filesystem, I/O on FIFOs does not involve operations on the underlying device (if there is one).

А конвейер — частный случай использования такого файла. Т.е. переводить пайп как "конвейер" некорректно. Это всё равно, что переводить "снег" как "лопата", аргументируя это тем, что лопатой снег копают 

язык - несомненно. а плохо переводимую в принципе белиберду которая получается из переведенной документации?

точно, и тонкий стеб - как раз то что обязательно должно присутствовать в технической литературе. именно потому что в техлит-ре есть нюансы, ее нужно принимать максимально точно. И если вся терминология изобретена на одном языке, в переводе она потеряет, как ни старайся.

непрофессионал профессионально работать не может.

получается. на то они и непрофессионалы.

и тем не менее документацию на английском вы читаете

теория алгоритмов очень далека от мануала по башу. когда будет изобретен русский язык программирования, мануал по нему я прочту на русском. а вот KnR в переводе - страх и ужас.

вот представьте себе, знаю.

да, пожалуйста прокомментируйте. зачем переводить с английского, который по указанной вами же диаграмме, связан со всеми основными мировыми языками, на русский, который по той же диаграмме, связан с кучей никому, кроме пары племен на чукотке, неизвестных языков?

Пушкин и Достоевский не писали техническую литературу по CS, ее писали Тененбаум, Керниган с Ричи и прочие.

и что? У нас тут, на этом уютном форуме, в каждом посте пишут "папки" вместо "каталогов", и что?

ну я перевёл как-то info sed, если вы считаете, что получилась "белиберда", то прокомментируйте хотя-бы один абзац. Я старался, что-бы всё было связно и понятно.

в английском языке нет слова fi или esac. А слово cat имеет абсолютно другой смысл, непонятный непрофессионалам. Как я уже говорил, для обычного англоговорящего быдлаобывателя, cat — кошка. Т.ч. не нужно думать, что для англоговорящего, код на ЯП — открытая книга. Нет, для англоговорящего это даже сложнее, чем для русскоговорящего. У русскоговорящего нет ненужных ассоциаций, вроде "mount==гора" или "stack=стог сена" или "heap==куча/отсыпать". Для русскоговорящего это специальные термины, имеющие специальное значение, которое слабо связанно с сельским хозяйством.

Т.ч. если уж совсем строго, то тот "английский", что в документации, это совсем другой английский.

Этот список спорных и не очевидных в переводе терминов... он выложенный здесь чтобы обозначать текущий оставшийся фронт работ. обсуждать на форуме его будет крайне не удобно...

регистрируйся через web-морду и стучись
несколько в меру глупых мыслей, к прочтению: Перевод "Advanced Bash Scripting Guide"

да, меня с «named pipe» переклинило...

по контексту, в случае употребления как существительное, «конвейер» [хорошо ложится на перевод.

«файл, начинающийся с точки», конечно, как вариант... хотя хочется термина покороче...
это перевести надо т.к. встречается, как минимум, в трёх различных местах и хотелось бы соблюсти единообразие.

табличка сарказм пропущена?

описывая --help говорить «дефис-дефис-help» как-то странно, не?

упоминается только на одной странице с определением, что это «начальное значение ГПСЧ»... ЕМНИП такой перевод я уже где-то встречал...

цель глоссария — определиться с переводом или его отсутствием спорных и встречающихся множество раз терминов... ИМХО

Ну почему?... Для названия главы "Расширяя горизонты." подойдет даже очень неплохо... Да и сохранение смысла будет...

дык, у многих есть ассоциация подобного написания с расширением...
...где-то из области оффтопика, хотя и не только там это употребляется...
dll-файлы; txt-файлы и т.д.

я бы хотел разделить два термина: писать «оболочка», когда речь идёт об абстрактной оболочке операционной системы и «shell», когда речь идёт о какой-либо пост-BourneShell-unix-оболочке. Правда не знаю, на сколько это получится и на сколько корректно...

это нужно выяснять отдельно для каждого контекста.

может никак не переводить? Лучше уж заимствовать термин, чем применять заведомо некорректный перевод, который к тому же используется в совершенно другой операционной и файловой системе? Особенно учитывая, что в GNU/Linux никаких "скрытых файлов" нет, и быть не может.

Если подумать, то вообще непонятно, зачем нужно скрывать файлы от самого себя? ИМХО это только вредителям нужно, например вирусмейкерам. А обычному человеку нужно просто "не показывать не нужные (в данный момент) файлы, например те, которые нужны самой системе. Ну например ~/projects/project/.hg/. Этот каталог мне безусловно нужен, но напрямую я туда никогда не лезу, а только через специальный интерфейс(причём в 95% случаев система сама этим занимается).

ИМХО нет, хотя конечно не знаю.

говорите "двойной дефис", как в оригинале:

зачем придумывать свою терминологию, если есть готовая?

это называется "надмозг". Вы ещё как «сперма» переведите.

не только. Вообще определить терминологию используемую автором, а тем более авторами.
ВНЕЗАПНО разночтения встречаются намного чаще, чем вы думаете. Даже математики не могут определится к примеру: 0∉ℕ? Потому и нужен глоссарий, хотя-бы для того, что-бы написать:

Натуральные числа, это числа 1,2,3,4… и так далее.

На самом деле, это не общепринято. И это в математике, которой уже Over9000 лет.

AFAIK «ветвление» — общепринятый термин. А «ответвления» — совсем другое.

facepalm
https://ru.wikipedia.org/wiki/%D0%93%D0 … 0%B5%D0%BB

И да, в bash ГПСЧ сделан "для галочки", и НЕ годен для применения. Причина в том, что есть /dev/random и /dev/urandom. Ну а $RANDOM — так, баловство.

кстати. Прочитал статью, ОЧЕНЬ ПЛОХОЙ ПЕРЕВОД. Да и оригинал https://en.wikipedia.org/wiki/Pseudoran … _generator тоже не очень. В том смысле, что оригинал написан не программистом и не для программистов. Математиком наверное. А переведён явно каким-то ГСМом.

so-файлы, тарболы

https://en.wikipedia.org/wiki/Tar_%28computing%29

За, всеми частями тела 

как по мне то переводить не стоит а просто оставить "--help"

согласен с drBatty, лучше оставить термин dotfiles

"от простого к сложному" 

нормально, ничего против не имею.

не понимаете.
«скрытый файл» == "hidden file", особый атрибут файла в FAT/NTFS, в MS-DOS/Windows.

Исторический экскурс:

Когда-то очень давно, когда у меня ЕЩЁ не стоял, деревья были зеленее, дома были выше, а компьютеры были больше. В смысле по размеру. И по числу терминалов. На них куча народу работало, причём сразу. И что-бы они друг другу не мешали, придумали права доступа. А потом появились персоналки, и решили, что прятать файлы от самого себя, может только идиот. Ну права и отменили. Также выяснилось, что есть смысл часть файлов прятать от юзера, это те, которые сама система использует. Для этого придумали фичу "скрытые файлы", вместо файлов, которые начинаются с точки. Это было оправданно потому, что в имени файла было всего 8 букв(ASCII), и тратить целую восьмушку имени было неразумно.

С тех пор прошло много лет, всё стало иначе, но ВНЕЗАПНО выяснилось, что "кривое не может сделаться прямым"©Екклесиаст, т.е. если что-то когда-то отменили, и заменили на другое, обратно изменить НЕЛЬЗЯ, ибо поломается совместимость. Сначала с OS/2, потом с MS-DOS, потом с Win9x, потом с WinNT, и т.п. Старый софт этого не поймёт. В итоге, нормальных прав в той ОС до сих пор нет, а есть только костыль ACL и реликтовые "hidden files", которые давно уже никто не использует, кроме школьников и/или вредителей.

Ну а в *NIX так и остались "dotfiles", потому что
1. длинна имени уже много лет как 255 байт, и потеря одного байта никого не волнует.
2. dotfiles нужны только системе, и мало кого волнует из пользователей, как они там называются. С другой стороны, не существует естественных языков, в которых есть слова/предложения, начинающиеся с точки. Т.ч. пользователь так файлы и не называет.

Однако, нельзя переводить "dotfiles" как "скрытые файлы" для того, что-бы никто не спутал их с настоящими, Ъ скрытыми файлами, которые до сих пор существуют, хоть и реликты из другой эпохи. Напротив, необходимо указать: «не путайте с "hidden files" из FAT/NTFS».

Программистам я предлагаю изучить Д. Кнута, у которого это всё подробно и обстоятельно разжёвано. Со ссылками и примерами реализаций.

А не-программистам ИМХО это и знать будет не интересно. В двух словах: это начальное значение ГПСЧ, от которого непосредственно зависит вся последовательность. Используется при отладке программы, что-бы псевдослучайные числа были вполне не случайными, а всегда одна и та же последовательность.
for example

на самом деле — мимо кассы. Это ваше "простое" было в другой главе, а в этой главе как раз довольно сложное. Гуглотранслятор даёт очень неплохой вариант(по смыслу)

За пределами основ