Call for testing: OpenSSH-6.2

[Ángel González]

Philip Hands writes:
> Ángel González <keisial at gmail.com> writes:
>> Well, there's the usual offender of Solaris sh
>> (fails with syntax error at line 36: `DEFAULT_PUB_ID_FILE=$', so not too
>> bad,
> "Not too bad" in the sense that it gets as far as the first line of the
> script before failing?  ;-)
>
> So Solaris portability will require replacing $(...) with `...` *sigh*

'Not too bad' because it hasn't processed yet anything, so it's harmless.


>> it also has a broken ${FOO:+BAR} syntax, printing BAR instead of $BAR)
> That's correct behaviour -- you do ${FOO:+$BAR} if that's what you
> wanted.  I'm using it to avoid adding an extra space to a list of
> options, thus:
>
>   X="${X:+$X }..."
>             ^
> (so the space after the $X only gets added when $X is already set)

Sorry, you're right. I thought I had tested it in bash, but apparently it
was just its documentation what confused me:
> `${PARAMETER:+WORD}'
>      If PARAMETER is null or unset, nothing is substituted, otherwise
>      the expansion of WORD is substituted.






>> The first thing I notice of your script is the missing \n at the end of
>> the usage (why are you using printf instead of echo?).
> Well, echo is depressingly unportable, so I recently decided that I'd
> spent enough time thinking about whether each usage of echo was going to
> be portable, so why not avoid the problem completely.  This lays out the
> problem:
>
>   http://www.etalabs.net/sh_tricks.html
>
> of course, that's where the missing \n bug came from -- thanks for
> spotting that.
>
> Note to self: changes that are too trivial to introduce bugs ... aren't
In this case, I think echo would be safe, as it'd be followed by a
string literal ("Usage:"),
but adding that newline to printf is also fine, of course :)



>> Finally, the error (usage parameters) given if you don't have an agent
>> running is not helpful.
> How are you getting that?  Is this still somehow with Solaris?
>
> It _should_ spit out:
>
>    ERROR: No identities found
>
> If you could describe what you did to get that, assuming that it still
> happens with the latest version, I'll see if I can work out what's going
> on.
With either no agent (just unset SSH_AUTH_SOCK and SSH_AGENT_PID) or an
empty agent (you can overwrite your 'normal' agent with a new one in a
shell instance)
I get with the latest version (fdb4641):

$ ./ssh-copy-id host

./ssh-copy-id: ERROR: failed to open ID file '/home/user/.ssh/id_rsa':
No such file or directory


The usage problem seems to be due to the getopt version that it is
picking Solaris
In Linux:
$ getopt --options 'i::o:p:nh?' --name "ssh-copy-id" --quiet -- "hostname"
 -- 'hostname'

In Solaris:
$ getopt --options 'i::o:p:nh?' --name "ssh-copy-id" --quiet -- "host"
-- i::o:p:nh? --name ssh-copy-id --quiet -- host

So $# is 6, thus it enters the if [ $# != 1 ] path.
Seems it's a traditional getopt, which only expects the options to be
the first parameter and $@ the rest of the arguments.


> Perhaps you'd be kind enough to give this a go on solaris for me:
>
>   http://git.hands.com/ssh-copy-id?p=ssh-copy-id.git;a=blob_plain;f=ssh-copy-id;hb=refs/heads/solaris
>
> I have a suspicion that if it doesn't like $(...) it might not like
> $((maths)) much either.
As expected, it doesn't.
$ echo $((5 + 1))
syntax error: `(' unexpected

For the two additions you use, expr is more than enough.


It would also be interesting if we had some tests for ssh-copy-id which
could then be run on the different systems, instead of making up them
each time.