https://bugzilla.mindrot.org/show_bug.cgi?id=2750
--- Comment #14 from [email protected] --- (In reply to Darren Tucker from comment #7) > (In reply to jg from comment #6) > [...] > > This has debug output: > > sftp -oLogLevel=debug3 -P 2222 [email protected] > > > > This has *no* debug output: > > sftp -P 2222 [email protected] -oLogLevel=debug3 > > > > Is that a separate issue? > > No, that's just how getopt works. Well, sometimes. On some > systems. It's complicated. > > Quoting getopt(3) on Fedora: > > "If the first character of optstring is '+' or the environment > variable POSIXLY_CORRECT is set, then option processing stops as > soon as a nonoption argument is encountered." > > and on OpenBSD: > > "When all options have been processed (i.e., up to the first > non-option argument), getopt() returns -1." > > If the getopt on the platform you're building on doesn't have a > particular feature (optreset) then the one in the compatibility code > will be used and that has the BSD semantics. This is usually the > case on Linux. > > ssh(1) is a bit special in that it'll accept -opts after the > argument (usually the host) regardless, but that behaviour dates > back decades and changing it now would probably break about a > gazillion scripts. Hi Darren would be good if options after would be processed too, I wonder if GNU getopt() is ok. Or an alternative could be integrated. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
