Это могла бы быть проблема, связанная с использованием Вашего ssh ключа? На удаленном сервере проверьте свой ключ authorized_keys
файл и проверяет, что Вы не сделали ограничил позволенное использование с command=
параметр. Больше информации о формате файла доступно по http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html.
Во-первых, в стандартном getopt()
-стиле обработки аргументов, аргументы не должны быть зажаты против опции, к которой они применяются, они просто могут быть. Таким образом, если -f
принимает аргумент, то и то, и другое является действительным:
command -ffoo positional arguments
command -f foo positional arguments
То, что вы называете "второй интерпретацией", на самом деле очень, очень редко. Насколько я могу судить сейчас, tar
и mt
являются единственными сохранившимися командами, которые так работают... и, как вы упоминаете, jar
, но это только потому, что они эмулируют tar
. Эти команды обрабатывают аргументы совершенно иначе, чем стандартные getopt()
-стиль. Этим опциям даже не предшествует -
! Не могу точно сказать, почему он редко использовался, но догадываюсь, что это из-за того, что сложнее сказать, какие опции идут с какими аргументами. Например, если b
и d
принимают аргументы, а a
, c
, и e
не принимают, то у вас есть следующее:
command abcde b-argument d-argument
..... что означает, что во время составления команды вы должны оглянуться на группу букв опций, прочитать ее еще раз, вспомнить, какие опции требуют аргументов, и записать аргументы в том же порядке. А как насчет этого?
command adcbe b-argument d-argument
Упс, опция d
получила b-аргумент
и наоборот. Хуже того, если вы видите:
command lmnop foo bar baz
... и не знакомы с командой, вы понятия не имеете, какие аргументы идут с какими опциями. foo
, bar
и baz
могут быть аргументами к n
, o
, p
(и l
и m
не принимают аргументов) или foo
и bar
могут идти, скажем, с m
и p
, в то время как baz
является позиционным параметром. ... или многие другие возможные комбинации.