Test version of a new PiDP-11 installation script

[terri-...@glaver.org]

I have been working on a complete rewrite of the existing install.sh script.

It asks about things in the wrong order, asks about some things twice, and

doesn't ask at all about other things. And it doesn't have a consistent style

throughout. This isn't a swipe at Oscar - he freely admits that his skills are

in the area of crafting exquisite replicas and not the software that runs on

them.

I have re-written it in a more DEC-like style, where it proceeds in defined

phases. For example, it asks all installation questions before doing any

actual installation work, provides optional detailed explanations for each

question, and lets users review (and potentially change) their answers be-

fore performing any actual installation work.

This script currently doesn't actually DO anything, so it is perfectly safe

to download and run it on an existing PiDP-11 system. 

While it doesn't make any changes to an existing system, I would like to

have as many people as possible try it out. In addition to possible spell-

ng and punctuation errors, I'd like to gather as much user feedback as

possible before adding the actual installation parts - the user dialog is

the hard part, not the actual commands that will perform the installation. 

Download it from: https://www.glaver.org/PiDP-11/v2-install-test.sh

It does not need to be placed in /opt/pidp11 - you can just put it in your

default login directory.

To use it, do:
chmod +x v2-install-test.sh (You only need to do this once.)

./v2-install-test.sh

You can either provide feedback here, or use "Reply to author" if you

don't want other people to see your feedback.

[Steven A. Falco]

I tried the new script and I really like it.

My only comment is that the initial explanation talks about answering y or n, but some of the questions require something like c for compile or g for gui. That is understandable, but perhaps there is a better wording for the initial message. Other than that tiny nitpick it all looks great!

Steve

> --
> 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 visit https://groups.google.com/d/msgid/pidp-11/2c4b4686-0d4f-4801-a7da-0861bdf8fe7en%40googlegroups.com <https://groups.google.com/d/msgid/pidp-11/2c4b4686-0d4f-4801-a7da-0861bdf8fe7en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[terri-...@glaver.org]

On Monday, November 17, 2025 at 9:23:41 AM UTC-5 steve...@gmail.com wrote:

I tried the new script and I really like it.

My only comment is that the initial explanation talks about answering y or n, but some of the questions require something like c for compile or g for gui. That is understandable, but perhaps there is a better wording for the initial message. Other than that tiny nitpick it all looks great!

 

Excellent point. I'll look into re-wording it in the next iteration.

BTW, the script is written in BASH, since that is what the original used.

I don't particularly like BASH as it isn't really suited for this type of com-

plex dialog structure which can loop back on itself.

What I'm getting at with that last comment is that I hope people try the

script with various types of input (each valid choice, invalid choices, and

so on). In particular, to make sure the description you get when you say

"always provide a detailed description" vs. typing ? for a description of a

specific question, and so on. Also, please look at the list of settings at

the end of the installation and make sure they match your answers. A

setting of "skip" means that the question was not asked because it was

only relevant if a preceding question was asked - for example, you don't

get the desktop questions if you told the installer you were running the

system without a desktop.

[Anton Lavrentiev]

Thanks for putting it all together, Terri!

I only eyeballed the script, and ... shouldn't these two "if" clauses end with "exit 1"?

if [ ! -f "/etc/os-release" ]; then

  error_cause="norelease"
  echo
  echo "Error: Cannot determine OS version (missing /etc/os-release file)."
fi
#
# Check to make sure we're running under Bookworm or Trixie
grep -iE "bookworm|trixie" "/etc/os-release" > /dev/null 2>&1
if [ $? != 0 ]; then
  error_cause="nobookworm"
  echo
  echo "Error: OS version is not Debian Bookworm or Trixie."
fi

--
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.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/bf3a69b0-5c9e-4b86-ac1a-1135145f0534n%40googlegroups.com.

[terri-...@glaver.org]

[My apologies to the people who received two replies I subsequently

deleted as incorrect on my part.]

On Monday, November 17, 2025 at 3:51:00 PM UTC-5 Anton L. wrote:

Thanks for putting it all together, Terri!

No problem! It's something  I felt was long overdue, and now that work on

the basic emulator (LED freezes and user-configurable knob rotation and default 

settings) is done, it's something I wanted to tackle next. The terminal emulators

are a whole 'nother can of worms, and I'm waiting for some upstream changes 

as well as a possible additional terminal emulator before I go back to those.

 

I only eyeballed the script, and ... shouldn't these two "if" clauses end with "exit 1"?

The first one should definitely cause an exit, instead of falling through to later

code that checks the error cause and then exits.

The second one has been changed to "Caution:" instead of "Error:" and now warns

the user that continuing with the installation may have unpredictable results. It 

then falls through to the "Do you want to cancel the install?" question.

[Ggrinton]

Adding my thanks, Terri.

A few relatively minor comments:

• I understand you want to limit the length of output lines, but I would prefer to start a new line rather than to use hyphenation. Just makes it easier to read, in my opinion.
• (Really trivial!) On line 234 there is what appears to be a superfluous "=" at the end of the line.
• Usually when you list allowed options, you include "?" (eg, line 265).  Maybe include the "?" on the list at line 310 as well?
• It is not clear to me why download of reference card, manual, etc (lines 512 to 623) are nexted inside the GUI conditional, as they could be of more geenral use.
• I use WSL at times when I don't want to fire up the PiDP11. No lights and switches, but useful if I just want a console. As you'll be aware, this script will not run in that (Ubuntu) environment.
• As others, and you, have noted, the initial explanation could refer to using the first letter of allowed responses, rather than just mentioniny y and n.

Geoffrey

[terri-...@glaver.org]

On Tuesday, November 18, 2025 at 4:10:36 AM UTC-5 Ggrinton wrote:

Adding my thanks, Terri.

A few relatively minor comments:

• I understand you want to limit the length of output lines, but I would prefer to start a new line rather than to use hyphenation. Just makes it easier to read, in my opinion.

Understood. There will likely be additional wordsmithing in a later version.  

• (Really trivial!) On line 234 there is what appears to be a superfluous "=" at the end of the line.

Fixed, thanks! 

• Usually when you list allowed options, you include "?" (eg, line 265).  Maybe include the "?" on the list at line 310 as well?

It was missing from the prompt, but '?' was accepted and displayed the help text. The missing 

'?' has been added to the prompt.  

• It is not clear to me why download of reference card, manual, etc (lines 512 to 623) are nexted inside the GUI conditional, as they could be of more geenral use.

It downloads them and places shortcuts on the desktop. If you tell the installer you don't have

a desktop (for example, "Raspberry Pi OS Lite"), it believes you. 8-} I could add a display of the

URL to download the tips and hints file at the end of the installation if the user selected the non-

GUI install. Links to download the skipped items will be in that file. I've added that to the TODO 

list.

• I use WSL at times when I don't want to fire up the PiDP11. No lights and switches, but useful if I just want a console. As you'll be aware, this script will not run in that (Ubuntu) environment.

Yes. But neither will the official https://github.com/obsolescence/pidp11 version of the old

installer. If that installer actually works under WSL, let me know and I'll look into it. But I'd be

surprised.

Are you running a separate set of PDP-11 operating system images on WSL, or do you share

them somehow with the PiDP-11? I'm asking because if you are using different images, you

could just run a Windows build of simh (in fact, I have binary builds of Open-SIMH 4.1.0-

Current in my github repo). Open-SIMH has progressed quite a bit from the version that the

PiDP-11 is frozen at (upstream declined the Blinkenbone patches, and they're too compli-

cated to manually merge into Open-SIMH, or at least I don't have that amount of time or

familiarity with SIMH internals). If you are sharing the OS images, I can probably come up

with a way to run them under Windows without going through this installer.

At some point I might actually build a native Windows installer which will ask most of the

same questions, but will give you a full install minus the PiDP-11 front panel support. But

that will need to wait until I finish the V2 install script. A Windows install will use mostly

the same directory layout, but with some cleanup and re-organization. I'm sticking with

the official https://github.com/obsolescence/pidp11 layout in my v2 install script, since
I don't want to shuffle things around - it should be possible to run the v2 install script to

update an existing PiDP-11 without leaving a bunch of duplicated stuff and other cruft

hanging around post-install. Note that the above sentence applies to people using the

GitHub version of the software. The old download-and-unpack install is very different from

the GitHub version (the GitHub version is more closely based on the PiDP-10 script, with

pdpcontrol, etc.).

• As others, and you, have noted, the initial explanation could refer to using the first letter of allowed responses, rather than just mentioniny y and n.

This is also on the TODO list.

Thanks!

[terri-...@glaver.org]

I have updated the new installation script with much user feedback, particularly

the concerns about changing the default simh and screen attention characters,

as well as always asking about installation of the terminal emulators and other

utilities and documentation, regardless of whether the installation selected the

GUI or headless option.

I haven't yet addressed the requests to not use hyphenation in descriptions, or

to explain that single-character answers other than 'y' or 'n' are possible. I want

to get all of the basics done before that level of polishing.

As before, this installer doesn't actually DO anything - it's just a much fancier user

interface for the installation questions (and quite a few new options as well), so

it is perfectly safe to run it on an existing PiDP-11 system - it won't change any-

thing.

You can download it (currently version T2.0-20251224) from:

https://www.glaver.org/PiDP-11/v2-install-test.sh

The original announcement is shown below:

[Ggrinton]

Thanks for the update.

Character remapping: For the SIMH interrupt control character, you ask the user to reply with the preferred character (E/P). However, in the following question, which is also asking for a control character selection, you ask for a yes/no answer. For consistency and to avoid confusion, it would be good to ask the questions in the same way each time.  Later, in the "review", it would be helpful to display the actual character being selected for the screen 'attention' function.

In the autostart question you ask for an explicit value for the answer. Usually, where there are only two options, you only ask yes/no.

I know these are just style decisions, so happy to make the comment and leave it there.

Geoffrey

[terri-...@glaver.org]

On Saturday, December 27, 2025 at 4:02:09 AM UTC-5 Ggrinton wrote:

Thanks for the update.

You're welcome!

 

Character remapping: For the SIMH interrupt control character, you ask the user to reply with the preferred character (E/P). However, in the following question, which is also asking for a control character selection, you ask for a yes/no answer. For consistency and to avoid confusion, it would be good to ask the questions in the same way each time.  Later, in the "review", it would be helpful to display the actual character being selected for the screen 'attention' function.

The issue is that Linux doesn't like "\" as an answer. That's why the screen question is yes/no.

I could change the SIMH interrupt question to "Change SIMH interrupt to ^P (yes/no/?, default is no)? " for consistency. That's easier than trying to deal with '\' as an input character. This seems to be the best solution.

In the autostart question you ask for an explicit value for the answer. Usually, where there are only two options, you only ask yes/no.

The autostart question only gets asked if the prior answer to the integrate question was 'yes'. Either answer to the autostart question is affirmative, it just wants to know which method it should use.

Right now both "review" and the "run off the end of the script" variable reports are just "naked". As the header to that report says:

  echo "Note: In this test version, these are printed with their internal names"
  echo "and values. In the actual release, these will be 'pretty printed' and"
  echo "internal-only variables will no longer be printed."

I know these are just style decisions, so happy to make the comment and leave it there.

I appreciate the input, thanks! 

[terri-...@glaver.org]

Ok, one more (hopefully final) round of the "do-nothing" installation script before I move on to actually adding

the real installation work.

This one incorporates a number of user suggestions, including eliminating as much hyphenation as possible

in messages displayed by the script, changing the SIMH interrupt question to a yes/no style, clarifying the intro

by explaining that if you answer 'no' to a question about installing an optional feature in a subsequent re-run 

of the install script, the feature will not be removed if previously installed, always using 'foo' when talking about 

option foo, instead of sometimes saying foo and other times saying 'foo', clarifying that if you answer 'no' to to 

the "Are you satisfied with your answers?" question, your previous answers are not used as defaults - you have 

to specify everything again. And it defaults to leaving the SIMH and screen attention characters as their existing 

ones, although the extended help messages for both recommend changing them.

And most importantly, it attempts to check what desktop environment you are running. Sample output looks

like one of these:

This Raspberry Pi is running a 64-bit operating system.
It appears to be using the X11 display system.

This Raspberry Pi is running a 32-bit operating system.
It appears to be using the Wayland display system.

This Raspberry Pi is running a 64-bit operating system.
It appears to be running without a display system (headless mode).

This Raspberry Pi is running a 64-bit operating system.

Caution: Unknown display system 'foo' detected. Proceed
         with caution as this has not been tested.

This is a amd64 Linux system, not a Raspberry Pi.
Caution: This architecture has received limited testing. In particular,
         desktop shortcuts may not function properly.
It appears to be using the Wayland display system.

In particular, this new environment check needs to be tested by as many people as possible. I

would particularly like to hear any reports of it "guessing" the display system incorrectly, or if

it detects an unknown display system. Even if you have previously tested the new installer, 

please download the latest version from:

https://www.glaver.org/PiDP-11/v2-install-test.sh

and test it as much as possible. I WANT you to try to break it or get it to misbehave in some man-

ner. Remember, right now it doesn't actually DO anything, it just asks you a lot of questions and

provides nice explanations on request, so it is perfectly safe to run on an existing PiDP-11 system.

If all feedback I get is positive, I will move on to the "actually doing the install" bits, which is quite

a bit easier than all of the configuration dialog that I've written so far. 

Thank you all for your patience and repeated testing of different versions, as well as the infor-

mative discussion about changing the SIMH and screen attention characters and other feed-

back.

[Ggrinton]

Thanks again. Nice!

I know we discussed this earlier and that it is effectively out of scope for what you are doing, but I tried again to run it under WSL on Windows. 

Just FYI, it initially failed . A bit of simple digging showed that this was because 'dpkg-architecture' was not found.

gg:~$ echo $(dpkg-architecture --query DEB_HOST_ARCH)
Command 'dpkg-architecture' not found, but can be installed with:
sudo apt install dpkg-dev

After running that install, the script runs and correctly identifies that:

This is a amd64 Linux system, not a Raspberry Pi.

Geoffrey

[terri-...@glaver.org]

On Sunday, December 28, 2025 at 5:16:25 AM UTC-5 Ggrinton wrote:

Thanks again. Nice!

I know we discussed this earlier and that it is effectively out of scope for what you are doing, but I tried again to run it under WSL on Windows. 

Just FYI, it initially failed .

By "failed" do you mean you got some sort of unexpected error

message (from the script or WSL) or did it just say:

  Error: This system is running on an unknown platform / architecture:
         something something
         Installation cannot proceed.

It should fail cleanly in this case. If not, I need to fix it.

A bit of simple digging showed that this was because 'dpkg-architecture' was not found.

gg:~$ echo $(dpkg-architecture --query DEB_HOST_ARCH)
Command 'dpkg-architecture' not found, but can be installed with:
sudo apt install dpkg-dev

After running that install, the script runs and correctly identifies that:

This is a amd64 Linux system, not a Raspberry Pi.

And presumably cautions you that there has only been limited

testing done on amd64?

Does it proceed as expected past that point (including the de-

tection of the windowing system in use)? What does it say the

windowing system is?

Once the installation phases are implemented, it will likely go 

"kaboom" in exciting ways. I added "apt install" for all of the

packages that are pre-installed on the Pi (where the install is

redundant) but missing from a vanilla Debian install in a VM.

Once we get to that point, we can work together to identify any

other packages that WSL didn't install that are pre-installed in

stock Debian. 

If you installed something other than Debian in WSL, I'm afraid

all bets are off...