Вопрос по stdin – Как перенаправить стандартный ввод в файл в командной строке Windows?

Question

Вопрос по stdin – Как перенаправить стандартный ввод в файл в командной строке Windows?

11

Задан 31 May 2012, 10:39 от JoeyMatt

11

На Unix я бы сделал что-то вроде:

cat > file.txt

Как я могу сделать это в командной строке Windows или командном файле?

EDIT: В основном, я ищу функциональностьcat без аргументов (он читает из stdin и выплевывает обратно в stdout).

+ 1 за использованиеtype такое классное и простое решение. Dominic P

01 Mar 2013, 01:34

@ Matt, да, это не совсем то же самое. Я не уверен, сколько вы работали с оболочкой Windows, но найти такое близкое приближение к функциональности * nix довольно редко / приятно в моем опыте. :) Dominic P

07 Mar 2013, 20:49

@ DominicP за исключением того, что он не работает для моих целей (читайте после "РЕДАКТИРОВАТЬ:") Matt

07 Mar 2013, 01:12

type thisfile > output.txt выдвигает все выходные так же, как unix cattype thisfile >> output.txt добавляет весь вывод в файл без перезаписи Kyle

30 May 2012, 21:02

4 ответа

Похожие вопросы

от Peter Mortensen · Answer 1 · 15 May 2013, 17:36

21

15 May 2013, 17:36 от Peter Mortensen

21

TYPE CON

CON - это устройство MS-DOS для консольного ввода. Вы можете перенаправить в файл следующим образом:

TYPE CON>output.txt

Чтобы прекратить, нажмите Ctrl + C или Ctrl + Z, Войт ( Ctrl + Z = EOF).

А как я мог забыть упомянуть Cygwin на этой машине с двойной загрузкой? : D Mark K Cowan

31 Jul 2013, 15:40

Слишком поздно, но, наконец, безрассудный ответ! Благодарность Matt

23 Jul 2013, 19:47

Ах, лол! Я думаю, это может быть полезно для других ... Я, наверное, единственный человек моего возраста, который знает об элегантномTYPE CON>LPT1 ярлык, чтобы превратить MS-DOS в пишущую машинку! Mark K Cowan

24 Jul 2013, 13:26

Windows альтернативы многим * nix командам существуют, но они «эволюционировали», а не были интеллектуально спроектированы, как bash, поэтому их немного сложнее найти и зачастую гораздо сложнее использовать, чем следовало бы ... Примером этой разницы является обратный удар bash по сравнению с эквивалентнымFOR построить в DOS. Слава Богу за Powershell и C # скрипт! Mark K Cowan

31 Jul 2013, 15:34

не забудь Cygwin! Matt

31 Jul 2013, 15:39

от dbenham · Answer 2 · 31 May 2012, 02:10

что вы читаете, в stdout, тогда FINDSTR может работать, в зависимости от того, как вы его используете.

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

findstr "^" file.txt

Трубы или перенаправление также могут работать, в зависимости от содержимого ввода:

findstr "^" < file.txt
or
type file.txt | findstr "^"

Вывод будет поврежден, если произойдет любое из следующего при использовании перенаправленного или конвейерного ввода с FINDSTR:

Любая строка ввода> 8191 байт Последняя строка ввода не заканчивается \ n. (команда может зависнуть при перенаправлении ввода)

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

FINDSTR также отличается от cat тем, что не может читать как из стандартного ввода, так и из именованного файла.

Видеть Каковы недокументированные функции и ограничения команды Windows FINDSTR? для получения дополнительной информации

от Carl Walsh · Answer 3 · 15 Jan 2015, 03:07

more.exe может быть то, что вы ищете.

Он может принимать данные как из консоли:

more > file1.txt

Или из другого файла, которыйTYPE CON Не справиться

type file1.txt | more > file2.txt

(more, кажется, добавляет новую строку к вашему файлу и расширяет вкладки, поэтому не используйте его для двоичных данных!)

от Peter Mortensen · Answer 4 · 31 May 2012, 01:05

0

31 May 2012, 01:05 от Peter Mortensen

0

Пакетный файл:

:: set /p MyVar=   Prompts user for stdin information

set /p MyVar=

echo %MyVar% > filename

Впрочем, сначала нужно прочитать весь стандартный ввод, не так ли? Кажется, что это будет нецелесообразно, если стандартный ввод очень большой. Matt

30 May 2012, 21:08