наверное, ты просто не хочешь)... qcommand же сделал.
Да не делал я там ничего. Серьезно - сам посмотри на changelog. Видимо, так звезды сошлись в галактике, что поведение винды изменилось.
Попробую еще раз объяснить ситуацию. Ключ -p в строке описания ключей имеет за собой двоеточие. Это означает, что ключ требует парамтр. Параметр - это любая последовательность байт, оканчивающаяся пробелом. При этом между -p и параметром может быть сколько угодно пробелов или не быть ни одного. То есть все это:
-p /dev/ttyUSB0
-p/dev/ttyUSB0
-p /dev/ttyUSB0
одно и то же. Теперь возьмем ситуацию, когда параметр ключа -р не указан, например так:
qdload -p -a100500 -i file.bin
В этом случае, очевидно, в качестве параметра будет выбрано "-a100500", и программа попытается выполнить открытие порта (в варианте для винды) так:
open("com-a100500")
Как следствие, винда начинает вести себя непредсказуемо и вылетает вышеприведенное окно. Если же, например, изменить комстроку, переставив местами ключи:
qdload -a100500 -i -p file.bin
то open будет уже формироваться из имени файла-загрузчика, то есть
open("comfile.bin")
В результате система просто не найдет указанного файла и программа тихо завершит свою работу. Я думаю, это и есть объяснение причины такого нестабильного поведения винды.
Поскольку getopt физически не может проверить отсутствия параметра - чем параметр отличается от следующих элементов командной строки? - то ситуация грамотного решения не имеет.
а если в готовом скрипте-последовательности тебе нужно перейти к следующему шагу - очень удобно клацать на клавишу энтер - вводить пустой порт.
на картинке - модем уже с запущенным загрузчиком. соответственно этап 3а и загрузку я пропускаю.
А что мешает прямо в скрипте проверить размер строки, введенной с терминала, и если она равна нулю - не запускать утилиту вообще? Винда, конечно, убожество еще то, но хоть какой-то скриптовый язык у виндового шелла должен ведь быть?