BSD 2.11 missing chown

[Warren Hardy]

I did a fresh install from Oscar’s site, after some corrupted files. I am missing chown, it is not in /bin, nor is the source code in /usr/src. Does anyone know where I can find the source?

[Aaron Jackson]

chown is located in /usr/sbin. I suspect this is not in your path. Just
in case it is, the source for chown should be in
/usr/src/usr.sbin/chown.

Aaron

Warren Hardy writes:

> I did a fresh install from Oscar’s site, after some corrupted files. I am missing chown, it is not in /bin, nor is the source code in /usr/src. Does anyone know where I can find the source?

--
Aaron Jackson - M6PIU
Researcher at University of Nottingham
http://aaronsplace.co.uk/

[Warren Hardy]

Thank you.

[Jonathan Trites]

I have found this helpful where <xxx> is what file name you want to find:

find / -print | grep <xxx>

[Jason Vanick]

you can also do:

find . -name ls -print

example:

49% root--> find / -name ls -print

/bin/ls

/usr/src/bin/ls

50% root-->

or find names matching a wildcard:

50% root--> find / -name \*chown\* -print

/usr/man/cat2/chown.0

/usr/man/cat2/fchown.0

/usr/man/cat8/chown.0

/usr/sbin/chown

/usr/src/lib/libc/pdp/sys/profiled/chown.o

/usr/src/lib/libc/pdp/sys/profiled/fchown.o

/usr/src/lib/libc/pdp/sys/chown.o

/usr/src/lib/libc/pdp/sys/fchown.o

/usr/src/man/man2/chown.2

/usr/src/man/man2/chown.0

/usr/src/usr.sbin/chown

/usr/src/usr.sbin/chown/chown.c

/usr/src/usr.sbin/chown/chown.8

/usr/src/usr.sbin/chown/chown.o

/usr/src/usr.sbin/chown/chown.0

51% root-->

[Jon Brase]

I'll add that the "which" command, in contrast to modern implementations, and in contrast to its own documentation, seems to search a preset list of directories in addition to or instead of the user's path, and so can be used to find commands that are not necessarily immediately runable without a full path.

[Jason Vanick]

I wonder if that's dependent on what shell you're running, as it doesn't work that way on my system:

on tcsh (and csh):

52% root--> which chown

/usr/sbin/chown

53% root--> which ls

/bin/ls

54% root--> cd /bin

55% root--> which which

which: shell built-in command.

56% root--> cd /usr/bin

on sh:

# which which

/usr/ucb/which

#

# file /usr/ucb/which

/usr/ucb/which: executable c-shell script

#

I looked through the script and I see nothing that would indicate it's looking elsewhere on the system, unless maybe you have stuff specified in ~/.cshrc

talking about shells... does anyone have ksh source that will compile on 211bsd?  I know it's probably heretical to want to run ksh on bsd, but given that I grew up on SysV (r2, then r3.2, then r4) ksh would be nice to have.

-J

[Johnny Billquist]

How did you come to that conclusion?

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Jon Brase]

How did you come to that conclusion?
 

If I run (in sh):

PATH=
export PATH
/usr/ucb/which sh

I get

/bin/sh

Likewise for other commands.

If I then run which for something that doesn't exist on the system, e.g,

/usr/ucb/which sudo

I get:

no sudo in /bin /sbin /etc /usr/sbin /usr/ucb /usr/bin /usr/new /usr/local

And, in fact, if I add a directory to $PATH that isn't in the above list, which still fails to find executables in that directory.

Now, when I run tcsh, then it uses the shell builtin which, which behaves as documented, searching only and exactly the folders specified in $PATH.

[Johnny Billquist]

Aha.

As others pointed out, /usr/ucb/which is actually a c shell script. And
the first thing it does it suck in .cshrc from your home directory.

Dare I guess that this file exists, and sets the path?

Having which implemented that way do have some potential traps and
issues, such as this one...

Johnny

On 2019-05-25 00:02, Jon Brase wrote:
>
> How did you come to that conclusion?
>
>
> If I run (in sh):
>
> |
> PATH=
> exportPATH
> /usr/ucb/which sh
> |
>
> I get
>
> |
> /bin/sh
> |
>
> Likewise for other commands.
>
> If I then run which for something that doesn't exist on the system, e.g,
>
> |
> /usr/ucb/which sudo
> |
>
> I get:
>
> |

> nosudo in/bin /sbin /etc /usr/sbin /usr/ucb /usr/bin /usr/new/usr/local

> |
>
> And, in fact, if I add a directory to $PATH that isn't in the above
> list, which still fails to find executables in that directory.
>
> Now, when I run tcsh, then it uses the shell builtin which, which
> behaves as documented, searching only and exactly the folders specified
> in $PATH.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pidp-11/9f5c5c4c-2f76-435d-aa3e-d82a3145f024%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/9f5c5c4c-2f76-435d-aa3e-d82a3145f024%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Randy Merkel]

Am I using the wrong image? no chown in /bin or  /sbin;

    : ra(0,0,0)unix
    Boot: bootdev=02400 bootcsr=0172150
   
    2.11 BSD UNIX #11: Sep 9 16:28:47 PDT 2019  
        root@Mon:/usr/src/sys/PIDP11

    ra0: Ver 3 mod 3
    ra0: RA82  size=1954000
    attaching de0 csr 174510
    attaching lo0
   
    phys mem  = 3932160
    avail mem = 3553280
    user mem  = 307200

    September 10 12:13:04 init: configure system
   
    dz 0 csr 160100 vector 310 attached
    ra 0 csr 172150 vector 154 vectorset attached
    rx 0 csr 177170 vector 264 attached
    tms 0 csr 174500 vector 260 vectorset attached
    cn 1 csr 176500 vector 300 skipped:  No CSR.
    erase, kill ^U, intr ^C

    ...

    # ls /bin/chown
     /bin/chown not found
     # ls /sbin/chown
    /sbin/chown not found

Also /usr is empty

    # ls /usr
    #  

Followed the "Prepare your Pi" instructions @ https://obsolescence.wixsite.com/obsolescence/pidp-11-building-instructions

[Jon Brase]

The unpatched 2.11BSD image distributed for the PiDP-11 boots to a single-user mode shell with /usr unmounted. Exit the single-user shell with ctrl-D to continue booting into multi-user mode, once the system is fully up, /usr should be mounted.

[Randy Merkel]

D'uh! Logged into root and can now chown!

Thanks

[Johnny Billquist]

Gah. While true, I wish people would stop recommending booting up
without having a proper fsck run.

And with that said, chown is indeed in /usr/sbin

Johnny

[Randy Merkel]

By running fsck manually? I've noteced that when I exit single user mode the prompt says something after fast boot, no fsck. Is there a way to "slow boot?"

Thanks

[Johnny Billquist]

Yes, you can run fsck manually.

If you change a definition in the boot program, you can also get
automatic booting to multiuser, in which case fsck is automatically run.
If you are on a reasonable recent patch level, fsck will also not do
anything on file systems that are clean, which means it will boot pretty
fast in the "normal" case.

Ask again if you can't find how to do this, and I can go and look in the
code and point things out.

Johnny

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/f5695ada-fdf5-4faf-92eb-5dc99ab10c36n%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/f5695ada-fdf5-4faf-92eb-5dc99ab10c36n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[curt mayer]

the second stage booter is /boot.   you need to rebuild it with an edit, and you'll get an automatic boot to multiuser, along with a fsck.

so, go to /usr/src/sys/pdpstand

and edit the boot.c file and change the line that reads:

#define AUTOMULTIUSER 0         /* 0 = old behaviour, !0 = new (automatic) behaviour */

and define the variable thus:

#define AUTOMULTIUSER 1         /* 0 = old behaviour, !0 = new (automatic) behaviour */

then, write it out, and run 'make install'.  this overwrites /boot with the new version, and there you go.

then, the next boot will get you exactly what you want.

--curt