После перенаправления stdin с tty1 в файл процесс по-прежнему принимает ввод от tty1
tee >test2.eml test{3..10}.eml < test1.xml
прочитает источник только один раз и выполнит только одну команду. Это может быть не более эффективным для больших файлов и может способствовать фрагментации, поскольку tee будет записывать блоки данных в каждый выходной файл по очереди. Он также создает файлы с разрешениями в соответствии с вашей текущей umask вместо частичного или полного воспроизведения исходных разрешений, как это делает cp в зависимости от параметров.
Если вы хотите сохранить типизацию, просто используйте zsh в качестве оболочки (вот откуда эти конструкции {2..10} взяты из btw)
for f (test{2..10}.eml)cp test1.eml $f
Что очень коротко как ваш:
eval 'cp test1.eml 'test{2..10}.eml';'
, но более интуитивно понятный / разборчивый и более легко применимый к именам файлов с более проблемными символами.
С помощью zsh и при условии, что вы не отключили параметр multios , вы также можете сделать следующее:
<test1.eml >test{2..10}.eml
Здесь zsh выполняет tee внутри, а также вызывает cat . Так что он немного менее эффективен, чем подход tee .
Вы показываете особую ситуацию. Хотя lessработает с входным потоком на fd 0, ему нужен входной канал для взаимодействия с пользователем. Таким образом, он открывает другой файл, здесь fd 3, для чтения с клавиатуры. Это определенно НЕ stdin. Помимо (воспоминаний... ):В OpenVMS от DEC они -по умолчанию -различают SYS$INPUT и SYS$COMMAND, что как бы отражает представленную ситуацию...
stdin is /root/file. The process can only read from /root/file.
stdout is /dev/tty1. The process can read from and write to /dev/tty1 (though I don't know why the process needs to read from its own output...)
stderr is /dev/tty1. The process can read from and write to /dev/tty1 (again, why does the process needs the permission to read from the error logs that it outputs?)
И «stdout», и «stderr» указывают на один и тот же файловый объект, на который указывал один и тот же «stdin» до того, как он был перенаправлен с /root/file, а именно /dev/tty1. Все они были получены путем дублирования (2)одного и того же файлового дескриптора и имеют общие свойства (режимы :O_RDWR, файловый указатель и т. д. ). Вы должны думать о файловых дескрипторах как об индексах в массиве из (указателей с подсчетом ссылок ), где несколько указателей могут указывать на одну и ту же структуру. Оболочка не удосужилась изменить режимы доступа «stdout» и «stderr» с помощью fcntl(fd, F_SETFL, O_WRONLY), когда она перенаправляла стандартный ввод из file--, что было бы бессмысленно.
The last line is a non-standard stream. I don't know what it is for, but the process can only read from it.
Это тот, который lessиспользует для взаимодействия с пользователем.
The question: Even though the stdin is /root/file, I can still interact with the less process (ex. typing '/' to enter search mode and search for a word). This means the process still accepts input from the current virtual terinal (/dev/tty1). I thought that since the stdin is not /dev/tty1, I should not be able to interact with the less process via typing on the keyboard?
/dev/tty— волшебный путь, который всегда будет открывать управляющий терминал; в вашем случае /dev/ttyи /dev/tty1относятся к одному и тому же устройству (, которое может быть виртуальным устройством --псевдо-терминалом -)