Skip to content

Add wrappers around whiptail - #273

Draft
lurch wants to merge 10 commits into
RPi-Distro:bookwormfrom
lurch:wrappers
Draft

Add wrappers around whiptail#273
lurch wants to merge 10 commits into
RPi-Distro:bookwormfrom
lurch:wrappers

Conversation

@lurch

@lurch lurch commented Feb 18, 2025

Copy link
Copy Markdown

Fairly big change, so I've tried to break it down into manageable commits. I've tested this, and it all seems to work okay, but please review it carefully.

@lurch lurch changed the title Wrappers Add wrappers around whiptail Feb 18, 2025
@gordoste

Copy link
Copy Markdown

Given the maintainer seems to have limited time, I would recommend keeping the PR to just "what it says on the tin". Create separate PRs for each different thing so that they can prioritise. The "don't display composite-video on Pi400/500" seems much more valuable than refactoring IMHO - separating them allows the maintainer to decide without having to selectively pull commits.

@lurch

lurch commented Feb 27, 2025

Copy link
Copy Markdown
Author

"The maintainer" sits just a couple of desks away from me 😂 This isn't a high priority PR, I'm happy to wait until he has time to review it.

The "don't display composite-video on Pi400/500" seems much more valuable than refactoring IMHO

Yeah, ironically that was the original motivation for this whole PR, but I didn't want to add more special-case branches to:

do_display_menu() {
  if is_pi ; then
    if is_wayland; then
      if is_pifour; then
        FUN=$(whiptail --title "Raspberry Pi Software Configuration Tool (raspi-config)" --menu "Display Options" $WT_HEIGHT $WT_WIDTH $WT_MENU_HEIGHT --cancel-button Back --ok-button Select \
          "D2 Screen Blanking" "Enable/disable screen blanking" \
          "D4 Composite" "Enable/disable composite output" \
          "D5 4Kp60 HDMI" "Enable 4Kp60 resolution on HDMI0" \
          "D6 Onscreen Keyboard" "Enable on-screen keyboard" \
          "D7 Keyboard Output" "Select monitor used for on-screen keyboard" \
          3>&1 1>&2 2>&3)
      else
        FUN=$(whiptail --title "Raspberry Pi Software Configuration Tool (raspi-config)" --menu "Display Options" $WT_HEIGHT $WT_WIDTH $WT_MENU_HEIGHT --cancel-button Back --ok-button Select \
          "D2 Screen Blanking" "Enable/disable screen blanking" \
          "D4 Composite" "Enable/disable composite output" \
          "D6 Onscreen Keyboard" "Enable on-screen keyboard" \
          "D7 Keyboard Output" "Select monitor used for on-screen keyboard" \
          3>&1 1>&2 2>&3)
      fi
    else
      if is_pifour; then
        FUN=$(whiptail --title "Raspberry Pi Software Configuration Tool (raspi-config)" --menu "Display Options" $WT_HEIGHT $WT_WIDTH $WT_MENU_HEIGHT --cancel-button Back --ok-button Select \
          "D1 Underscan" "Remove black border around screen" \
          "D2 Screen Blanking" "Enable/disable screen blanking" \
          "D3 VNC Resolution" "Set resolution for headless use" \
          "D4 Composite" "Enable/disable composite output" \
          "D5 4Kp60 HDMI" "Enable 4Kp60 resolution on HDMI0" \
          3>&1 1>&2 2>&3)
      else
        FUN=$(whiptail --title "Raspberry Pi Software Configuration Tool (raspi-config)" --menu "Display Options" $WT_HEIGHT $WT_WIDTH $WT_MENU_HEIGHT --cancel-button Back --ok-button Select \
          "D1 Underscan" "Remove black border around screen" \
          "D2 Screen Blanking" "Enable/disable screen blanking" \
          "D3 VNC Resolution" "Set resolution for headless use" \
          "D4 Composite" "Enable/disable composite output" \
          3>&1 1>&2 2>&3)
      fi
    fi
  else
    FUN=$(whiptail --title "Raspberry Pi Software Configuration Tool (raspi-config)" --menu "Display Options" $WT_HEIGHT $WT_WIDTH $WT_MENU_HEIGHT --cancel-button Back --ok-button Select \
      "D1 Underscan" "Remove black border around screen" \
      "D2 Screen Blanking" "Enable/disable screen blanking" \
      3>&1 1>&2 2>&3)
  fi
  RET=$?
  if [ $RET -eq 1 ]; then
    return 0
	@@ -3850,28 +3944,25 @@ do_display_menu() {
      D5\ *) do_pi4video ;;
      D6\ *) do_squeekboard ;;
      D7\ *) do_squeek_output ;;
      *) whiptail --msgbox "Programmer error: unrecognized option" 20 60 1 ;;
    esac || whiptail --msgbox "There was an error running option $FUN" 20 60 1
  fi
}

...which is what started me on this refactoring journey 😉

Comment thread raspi-config
# Escape special characters for embedding in regex below
ssid="$(echo "$SSID" \
| sed 's;\\;\\\\;g' \
| sed -e 's;\.;\\\.;g' \

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this definitely functionally identical? I didn't write the original code here, but it looks as if the two sed statements do different things, and by splitting them like this, the first will definitely happen before the second. I don't know if combining them like this will ensure that that still happens?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be very surprised if sed 's/a/b/' | sed 's/c/d/'acted differently to sed -e 's/a/b/' -e 's/c/d/', but out of an abundance of caution I've done some testing, and it indeed appears to work as I expected:

$ echo "ffbfbfbb" | sed 's;f;F;g' | sed 's;b;B;g'
FFBFBFBB
$ echo "ffbfbfbb" | sed -e 's;f;F;g' -e 's;b;B;g'
FFBFBFBB
$ echo "start \\bslash\\ .dot. *asterisk* +plus+ ?question? ^caret^ \$dollar\$ /fslash/ [ls[ ]rs] {lb{ }rb} (lp( )rp) \"dquote\" end"
start \bslash\ .dot. *asterisk* +plus+ ?question? ^caret^ $dollar$ /fslash/ [ls[ ]rs] {lb{ }rb} (lp( )rp) "dquote" end
$ echo "start \\bslash\\ .dot. *asterisk* +plus+ ?question? ^caret^ \$dollar\$ /fslash/ [ls[ ]rs] {lb{ }rb} (lp( )rp) \"dquote\" end" | sed 's;\\;\\\\;g' | sed -e 's;\.;\\\.;g' -e 's;\*;\\\*;g' -e 's;\+;\\\+;g' -e 's;\?;\\\?;g' -e 's;\^;\\\^;g' -e 's;\$;\\\$;g' -e 's;\/;\\\/;g' -e 's;\[;\\\[;g' -e 's;\];\\\];g' -e 's;{;\\{;g' -e 's;};\\};g' -e 's;(;\\(;g' -e 's;);\\);g' -e 's;";\\\\\";g'
start \\bslash\\ \.dot\. \*asterisk\* \+plus\+ \?question\? \^caret\^ \$dollar\$ \/fslash\/ \[ls\[ \]rs\] \{lb\{ \}rb\} \(lp\( \)rp\) \\"dquote\\" end
$ echo "start \\bslash\\ .dot. *asterisk* +plus+ ?question? ^caret^ \$dollar\$ /fslash/ [ls[ ]rs] {lb{ }rb} (lp( )rp) \"dquote\" end" | sed -e 's;\\;\\\\;g' -e 's;\.;\\\.;g' -e 's;\*;\\\*;g' -e 's;\+;\\\+;g' -e 's;\?;\\\?;g' -e 's;\^;\\\^;g' -e 's;\$;\\\$;g' -e 's;\/;\\\/;g' -e 's;\[;\\\[;g' -e 's;\];\\\];g' -e 's;{;\\{;g' -e 's;};\\};g' -e 's;(;\\(;g' -e 's;);\\);g' -e 's;";\\\\\";g'
start \\bslash\\ \.dot\. \*asterisk\* \+plus\+ \?question\? \^caret\^ \$dollar\$ \/fslash\/ \[ls\[ \]rs\] \{lb\{ \}rb\} \(lp\( \)rp\) \\"dquote\\" end

Comment thread raspi-config
Comment thread raspi-config
Comment thread raspi-config Outdated

do_advanced_menu() {
if gpu_has_mmu ; then
if is_pifour ; then

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think gpu_has_mmu is the same as is_pifour - gpu_has_mmu should select both Pi 4 and Pi 5, IIRC - we introduced that test name to keep the existence of Pi 5 secret prior to release. I don't think changing this test is correct.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I split it into separate tests for Pi 4 and Pi 5 (rather than showing the same menu for both), because AFAIK the "Set PCIe x1 port speed" option is only applicable for Pi 5, and doesn't do anything on Pi 4?

Comment thread raspi-config
WT_WIDTH=$(tput cols)
WT_BOX_HEIGHT=20
WT_BOX_WIDTH=60
WT_BOX_WIDTH_WIDE=70

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it actually necessary to have two different widths, given they differ by so little? Might be tidier to just have one?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only did that for backwards-feature-parity with the existing code - happy to unify it to just a single width, if you let me know which one you'd like me to use 🙂 (I think when I tested this, some of the text in the "wider" dialogs wrapped weirdly when given a width of 60, which is why I added the "wide" variant.)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest using whichever is least risky - presumably the wider one - and testing to make sure it is still ok with the other messages. I'd assume the narrower one was historically the default but at some point it was found to cause problems with one or two particular messages.

@spl237

spl237 commented Mar 6, 2025

Copy link
Copy Markdown

OK, I've now read through all of this (I think...) and noted the specific issues as commented above.

Overall, this is a really big set of changes to the script, albeit ones which have a negligible change on the actual functionality. That sort of thing makes me instinctively wary, as I am reluctant to change things which are working - that said, I can see the sense in a lot of this, but it is difficult to be able to be sure that everything is correct when it all hangs on a single merge.

There are parts of this which are completely uncontentious, like the whiptail wrapper functions - those to me look low-risk and a good improvement to the code. There are other parts, like the menu generation code, which are going to require some very careful review to make sure nothing has broken in the process.

As a result, can I please suggest that this one PR is broken up into a few separate ones which can be reviewed and merged independently? As a suggestion, these should be at a minimum (and not necessarily in this order):

  1. Whiptail wrappers
  2. Menu generation
  3. Composite video change
  4. Any other changes to functionality

And possibly even further subdivided if it makes sense to do so. If we are going to do this - and as above, I can see the sense of a lot of it - I'd like to have the riskier stuff separated out from the non-contentious stuff to make sure that we can break this into bite-size chunks rather than having to accept a single monolithic merge. Many thanks.

@lurch

lurch commented Mar 6, 2025

Copy link
Copy Markdown
Author

I'd like to have the riskier stuff separated out from the non-contentious stuff to make sure that we can break this into bite-size chunks rather than having to accept a single monolithic merge.

Makes sense, I'll attempt to do that 👍 (need to put my "advanced git" hat back on again 🧙‍♂️ )

albeit ones which have a negligible change on the actual functionality.

That was deliberate - I didn't want to break/change existing functionality 🙂

@lurch
lurch marked this pull request as draft March 14, 2026 15:04
@lurch

lurch commented Mar 14, 2026

Copy link
Copy Markdown
Author
  1. Composite video change

That's now done in #299

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants