Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: on DragonFly, sh detection for HOST_SH, and configure cannot guess build type

On Thu, 01 Jan 2009, Jeremy C. Reed wrote:
> (on 5.0_BETA) has:
>  [ -z "${HOST_SH}" ] && HOST_SH="$(
>         (ps -p $$ -o comm | sed -ne '2s/[ \t]*$//p') 2>/dev/null )"
> "comm" is unknown on DragonFly. It does have "command" keyword.
> This results in HOST_SH being set to the unrelated ps output.

"comm" is standardised, see

If it's not supported, I'd expect the ps command to produce an error
message on stderr, and nothing on stdout, with the result that HOST_SH
remains set to the empty string.

> Also the \t is not a TAB in that version of sed/regex. It is a literal 
> letter "t".

That's a bug in; I'll change it to use [[:space:]], or maybe
avoid using sed at that point.

> So I used:
>         [ -z "${HOST_SH}" ] && HOST_SH="$(
> -               (ps -p $$ -o comm | sed -ne '2s/[ \t]*$//p') 2>/dev/null )"
> +               (ps -p $$ -o command 2>/dev/null | sed -ne '2s/[        
> ].*$//p') 2>/dev/null )"

That will truncate the command name after the first space.  I worry
about people keeping their shell in a directory whose name contains a
space (especially on Windows).

> Second issue was:
> checking build system type... 
> /build/reed/nb/src/tools/gmake/../../gnu/dist/gmake/config/config.guess: 
> unable to guess system type

I can't help you there (but see Alistair's reply).

--apb (Alan Barrett)

Home | Main Index | Thread Index | Old Index