Эхо в файловый дескриптор перезаписывает файл?
Да. Но , если нет веской причины, я бы не рекомендовал . Обычно существует какая-то причина, по которой система не имеет общего доступа к Интернету, и в этом случае лучше загрузить RPM в вашу собственную систему, затем загрузить их на сервер и использовать rpm для их установки из загруженных файлов. Или, если это обычное явление, настройте прокси-сервер репозитория и вместо этого разрешите конфиденциальным серверам доступ к нему.
Однако вот как вы это сделаете, если понадобится.
В удаленной системе измените информацию репозитория для официального дистрибутива, чтобы он указывал на порт 8080 (или какой-либо другой неиспользуемый порт). Добавьте строку в / etc / hosts , чтобы имя сервера репозитория указывало на 127.0.0.1.
На вашем собственном сервере запустите туннель SSH. Он должен перенаправить порт 8080 в целевой системе на порт 80 на сервере репозитория.
ssh -R 443:repository.example.org:80 theserver
Поскольку вы не читали дескриптор 88, текущая позиция поиска была «0», и поэтому запись имела место в этой точке.
Если вместо этого вы прочтете файл до этого, то произойдет добавление:
bash-4.2$ cat <&88
The quick brown fox...
The quick brown fox...
bash-4.2$ echo hello >&88
bash-4.2$ cat example.txt
The quick brown fox...
The quick brown fox...
hello
bash-4.2$ echo more >&88
bash-4.2$ cat example.txt
The quick brown fox...
The quick brown fox...
hello
more
Как правильно указывает @Zoonose, каждый файловый дескриптор имеет свою собственную позицию курсора чтения -записи в файле, к которому он подключен. И файл может быть открыт либо оболочкой, когда вы используете перенаправление, такое как <>, либо программой, такой как cat.
Но числа, которые вы считаете «файловыми дескрипторами», являются просто ссылками на фактические файловые дескрипторы в ядре, и совершенно нормально, когда один файловый дескриптор имеет несколько таких ссылочных номеров либо внутри одного процесса, либо между процессами.
Таким образом, когда вы открываете окно терминала (или входите в систему по ssh ), вы начинаете с одного файлового дескриптора, открытого на вашем терминале, подключенного как fd #0, fd #1 и fd #. ] 2 в вашем процессе оболочки. Любой процесс, с которого запускается оболочка, наследует их по умолчанию --, за исключением случаев, когда вы использовали каналы или перенаправления.
Перенаправление >>помечает дескриптор файла как O_APPEND, поэтому через пишется, что дескриптор файла игнорирует курсор и переходит в конец файла.
Перенаправление >приводит к усечению целевого файла только один раз, прежде, чем будет выполнена любая запись. Таким образом, любая запись после этого обычно идет в пустое место за концом файла.
Запись в файл не сама по себе вызывает усечение; они просто заменят все, что находится в текущей позиции, и при необходимости растянут конец -файла -.
Обратите внимание, что somecmd >&88заставит stdout (fd #1 )для somecmd совместно использовать дескриптор файла с fd #88 текущей оболочки. Это означает, что он будет использовать опцию O_APPEND,если имеется. Это не приведет к повторному усечению; это на один -раз.
В этом случае вы видите, что при использовании >&88нет усечения, потому что fd #88 не был открыт с помощью >>, поэтому записи из нескольких процессов могут чередоваться.