script(1) detection does not work on NetBSD

[0-wiz-0]

When running configure on NetBSD, I see:

checking for script... /usr/bin/script
checking /usr/bin/script's command line type... configure: error: could not determine how to invoke /usr/bin/script
*** Error code 1

config.log has a bit more:

configure:15970: checking for script
configure:15988: found /usr/bin/script
configure:16001: result: /usr/bin/script
configure:16009: checking /usr/bin/script's command line type
configure:16033: error: could not determine how to invoke /usr/bin/script

I tried running the tests manually, but both versions work for me on NetBSD-7.99.38/amd64:

# script -qfc "echo hello" /dev/null
hello
# echo $?
0
# script -q /dev/null echo hello
# echo $?
0

The second version enters a subshell though. If I run the second version without -q:

# script /dev/null  echo hello
Script started, output file is /dev/null
#<CTRL-D>
Script done, output file is /dev/null

[gvansickle]

Hello again @0-wiz-0 ,

What's a minimally painful way to get a NetBSD VM spun up? I've just spent way too long trying to get the standard 7.0.1 distro up and going, and I haven't even got a decent shell working yet. My attempts at setting up and using pkgsrc have been partially successful, but I've clearly overshot the happy path to a working setup. Something like a NetBSD version of PC-BSD would be just the ticket.

I was able to do some minimal investigation of NetBSD's script behavior. It is indeed behaving like you indicate above, and FWICT it should be getting detected as the "Linux" type. Without a more usable system though, I'm not going to be able to dig much further into this....

[0-wiz-0]

Hi again Gary!

Here's a howto for amazon aws: https://wiki.netbsd.org/amazon_ec2/

Is that painless enough?

[gvansickle]

Ah, yes, Amazon's AWS/EC2. I'm not a huge fan of:

Free Trial! But give us your credit card number anyway. Expires in 12 months. If you go over your Trial limits (which is pretty much guaranteed due to the fineness of our print) we'll bill you at a rate TBD. Some restrictions may apply. No bailment created. Not to be used as a flotation device.

Seriously though, I may have to start looking into that angle the way this ucg thing is taking the internet by storm. I knew I'd Go Viral(tm) one day. ;-)

Actually seriously now: My definition of "minimally painful" as used here is more along the lines of:

1. No money changes hands, nor potentially changes hands.
2. It comes in the form of an ISO which runs under Virtual Box or (more painful) VMWare Player.
3. Or an account I can SSH into and have enough permissions to do the necessary debugging.

Is there really no option for getting a proper NetBSD up and running between "Be a career NetBSD Sysadmin" and "Pay someone to do it"?

[refi64]

Some VirtualBox hard disks containing NetBSD are available at ftp://ftp.iij.ad.jp/pub/NetBSD/misc/GCi/. Not sure how old they are, but based on the README, they seems to be from 2011/2012.

There are some disks from 2013 here.

A torrent for an old version of NetBSD (from 2007) for QEMU is available on a mirror or FreeOSZoo, though I have no clue if it still works.

[gvansickle]

Thanks @kirbyfan64 , I'll take a look.....

[gvansickle]

Hey guys,

Ok, I have a NetBSD VM up and building ucg. But I can't duplicate the reported issue:

[...]
checking for script... /usr/bin/script
checking /usr/bin/script's command line type... Linux style
[...]

config.log says everything is OK:

configure:17685: checking for script
configure:17703: found /usr/bin/script
configure:17716: result: /usr/bin/script
configure:17724: checking /usr/bin/script's command line type
configure:17734: result: Linux style

uname says this:

$ uname -a
NetBSD netbsdvm.Home 7.0.1 NetBSD 7.0.1 (GENERIC.201605221355Z) amd64

I can't get script to give me a version, but ls -l says this:

 ll /usr/bin/script
-r-xr-xr-x  1 root  wheel  16623 May 22 09:48 /usr/bin/script

@0-wiz-0 , what does your script size/date look like? Are you sure you're building from master/HEAD? I'm not quite sure where to go from here....

[0-wiz-0]

Ok, thank you for testing. I've debugged this locally some more and found that script couldn't open the corresponding tty devices. The usual workaround is to mount ptyfs, which I hadn't done in my build environment. When I do that, I see the same as you. So nothing to see here, local setup error, sorry for the noise :(

[gvansickle]

Ok, no problem. Is this something common enough that I should maybe put in a configure check for it? E.g. is every NetBSD user (besides me I guess) going to run into this?

[0-wiz-0]

No, this should work by default and only break if you set up chroots and forget to mount ptyfs.

[gvansickle]

Ok, great. Thanks again.