В чем разница между записью файла в редакторе, таком как vim/nano, и перенаправлением вывода в оболочке?
Это наивный хак, работающий на предоставленных данных:
$ awk -F, 'NF != 3 { printf("%s",$0); getline } 1' file.csv
ABCD,1234,QWER
ASDF,2345,VGFT
1234,ZXCV,ERTT
Он использует awkдля анализа файла как набора данных, разделенного запятыми -. Если в строке не ровно три поля (NF != 3), то бит строки, который был прочитан до сих пор, выводится как есть без завершающей новой строки, и читается следующая строка. Окончательный 1является сокращением от { print }и выводит все строки.
Если сработал первый блок, то эти последние 1/ printвызовут вывод остатка ломаной строки в конце того, что было выведено printf.
Вариация этого сsed:
$ sed -E '/^[^,]+,[^,]+,[^,]+$/!{ N; s/\n//; }' file.csv
ABCD,1234,QWER
ASDF,2345,VGFT
1234,ZXCV,ERTT
Опять же,это может не сработать, если линии разорваны не так, как показано в примере данных.
Сценарий sedпроверяет каждую строку с помощью регулярного выражения ^[^,]+,[^,]+,[^,]+$. Если это соответствует, у нас есть строка, которая выглядит так, как должна; три поля, состоящие из символов, отличных от запятых, разделенных запятыми. Если это , а не , следующая строка добавляется в конец текущей строки с помощью N, а новая строка, которая sedвставляется между ними, удаляется.
Код sedследует той же логике, что и код awk, в том смысле, что он добавляет следующую строку данных, если текущая строка ошибочна.
Я нашел эту статью , которая, как мне кажется, объясняет вашу проблему.
Apple has introduced notarization, setting aside the inconvenience this brings to us developers, it also results in a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. This check for me takes close to a second.
This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay!
As for the notarization check, the result is cached, so second invocation should be fast, but if you are a developer, you may update your scripts and binaries regularly, which trigger new checks (it appears caching is based on inode, so an update-in-place save may avoid triggering a new check), or you may have workflows that involve dynamically creating and executing scripts, which performance now hinges upon the responsiveness of Apple’s servers.
Кажется, что изменение файла через редактор изменяет индексный дескриптор, вызывая его повторную проверку, а добавление к нему перенаправления — нет.