Comment 6 for bug 712614

Thank you all for your help. I'm really sorry for not being able to respond faster and I apologize for this.

Allow me to slap myself first:

1. using wordexp(...) isn't exactly the brightest idea (contrary) because: $IFS will probably create trouble in some scenarios and a save/restore on $IFS is needed from agetty. Plus, combining "-- logname" with an existent we_wordv array would create more mess. Last, wordexp code is heavy and its complexity doesn't pay for such a simple task. Furthermore,

2. Specifying login program parameters inside -l getty's optstring is very ugly (getty -l '/bin/login -p -f root') and what's more important it forces you to specify the /bin/login program even if it's the default

3. Indeed, omitting "-- logname" is an error. I probably thought only of the scenario when '-n' getty option is used (because otherwise there wouldn't be any "real" automatic login) and "-- logname" isn't needed anymore. It's an error, though. Ignoring (or not) the logname should (probably) be the task of login program, as it was before (in the original version, getty would still send "-- logname" even if -n getty option was used and there was no logname, probably at least for clarity/simplicity )

Now that I'm awake,

1. I properly integrated login parameters with getty. Now login parameters are specified following getopt() specifications related to end-of-options-scanning (for example):

getty -8 -n 38400 tty6 linux -- -f root -p

The parameters following "--" are to be passed to login program. Specifying login parameters this way is sound, stylish (from GNU/Unix/Linux point of view) and (from what I can tell) it doesn't affect in any way the existent functionality of getty on Linux platforms (I apologize for rushing into such an affirmation before). I am saying Linux because some platforms could have trouble with this format (snip from the manpage: Under System V, a "-" port argument should be preceded by a "--") but I (hopefully safely) ignored this information.
Because of the optional "terminal type" argument and the way getopt() works, there was some trouble in correctly identifying what really are getty parameters and what login parameters. To do it properly, I had to modify the getopt() optstring by adding the '-' mode and process the non-options as dummy-option optargs. This didn't change the code logic (the optional arguments are processed correctly), but only the flow (now the optional arguments are processed in the getopt() loop). I am saying this because there could be some trouble with the code on other systems I am only thinking FreeBSD, more specifically: Debian's FreeBSD project. I'm not familiar with it and I don't know how the code is handled over there or if this package has anything to do with it.

@Clint: Let me know if I should also submit this patch to term-utils (probably not or not yet)
@Clint: if you think this is useful upstream, I wont steal from you the pleasure of submitting it :)

successfully completed test scenarios (init tty confs snip, ubuntu 10.10 amd64 running patched version):
/sbin/getty -8 -n 38400 tty6 linux -- -f root #[OK_works_as_expected]
/sbin/getty -8 -n 38400 tty6 -- -f root #[OK_works_as_expected]
/sbin/getty -8 -n tty6 38400 -- -f root #[OK_works_as_expected]
/sbin/getty -8 -n tty6 38400 -- -f root #[OK_works_as_expected]
/sbin/getty -8 -n -l /usr/local/bin/login2 tty6 38400 -- -p #[OK_works_as_expected]
/sbin/getty -8 -n tty6 38400 -- #[OK_works_as_expected]
/sbin/getty -8 -n tty6 38400 #[OK_works_as_expected]

Thank you

p.s. new patch attached, the old one can be removed from universe