Bash shell, запущенный forkpty(), порождает дочерние процессы, которые игнорируют SIGINT. Почему и как мне убедиться, что SIGINT не игнорируется?
Команда похожа на sed , которая позволяет указать несколько замен с помощью параметр -e , например,
rename -n -e 's/\(feat.//' -e 's/ - //' *.mp3
и get
'103 Flume - Left Alone (feat. Jezzabell Doran).mp3' would be renamed to '103 FlumeLeft Alone Jezzabell Doran).mp3'
'214 Flume - Sleepless (feat. Jezzabell Doran) (Shlohmo Remix).mp3' would be renamed to '214 FlumeSleepless Jezzabell Doran) (Shlohmo Remix).mp3'
В документации сказано
-e,- exprАргумент кода для этого Параметр должен быть выражением Perl, которое принимает имя файла в переменной
$ _и изменяет его, чтобы имена файлов были переименованы. Если другие параметры-c,-C,-e,-sили-z] недоступны) учитывая, что вы можете опустить-eперед кодом.
Этот результат не может быть связан с блоком кода, который вы указали в своем вопросе. Должно быть что-то еще в других частях вашей общей установки.
Учитывая только описанный вами сценарий использования, наиболее вероятная причина заключается в том, что вы на самом деле установили SIGINT для игнорирования в своем коде где-то перед forkpty или перед execve в forkpty's ребенок.
Это дало бы результат, который вы описываете, потому что тогда ваш forkpty'ed bash -iунаследовал бы такую настройку SIGINT -, игнорируемую, и хотя он установил бы ее иначе для своих внутренних целей (, таким образом, не игнорируя SIGINT ). ] он также сбрасывал бы его в унаследованное игнорируемое состояние для каждой команды, которую он порождал.
Это задокументированное поведение Bash, см. справочную страницу Bash -в главе «СРЕДА ВЫПОЛНЕНИЯ КОМАНД»,в частности, абзац, говорящий:
When a simple command other than a builtin or shell function is to be executed, it is invoked in a separate execution environment that consists of the following. [...]
[...]
o traps caught by the shell are reset to the values inherited from the shell's parent, and traps ignored by the shell are ignored
ХТХ