Last digit of formula version number can be omitted when upgrading

[nwhetsell]

brew doctor output

Your system is ready to brew.

Verification

• My "brew doctor output" above says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update twice and am still able to reproduce my issue.
• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

brew config output

HOMEBREW_VERSION: 4.2.13-140-g9a1793a
ORIGIN: https://github.com/Homebrew/brew
HEAD: 9a1793a5ad5f400df6c2d53166a507c19bd02f93
Last commit: 13 hours ago
Core tap HEAD: 273b1649085d6a66a8995ff235b2204e22a46980
Core tap last commit: 76 minutes ago
Core tap JSON: 23 Mar 15:17 UTC
Core cask tap HEAD: 7e6b88eb16e6ac9e076415e2b445174e039b764a
Core cask tap last commit: 2 hours ago
Core cask tap JSON: 23 Mar 15:17 UTC
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 12
HOMEBREW_SORBET_RUNTIME: set
Homebrew Ruby: 3.1.4 => /opt/homebrew/Library/Homebrew/vendor/portable-ruby/3.1.4/bin/ruby
CPU: dodeca-core 64-bit arm_blizzard_avalanche
Clang: 15.0.0 build 1500
Git: 2.39.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.4.0 => /usr/bin/curl
macOS: 13.6.5-arm64
CLT: 15.1.0.0.1.1700200546
Xcode: 15.2
Rosetta 2: false

What were you trying to do (and why)?

Upgrade a formula (lilypond-unstable) from a non-Homebrew tap (https://github.com/nwhetsell/homebrew-lilypond).

What happened (include all command output)?

The last digit of the new version number was omitted (under ==> Upgrading nwhetsell/lilypond/lilypond-unstable)

% brew upgrade lilypond-unstable     
==> Upgrading 1 outdated package:
nwhetsell/lilypond/lilypond-unstable 2.25.13 -> 2.25.14
==> Fetching nwhetsell/lilypond/lilypond-unstable
==> Downloading https://github.com/ArtifexSoftware/urw-base35-fonts/archive/refs
Already downloaded: /Users/nathanwhetsell/Library/Caches/Homebrew/downloads/12fa9f20d07e79df9aa22021608f4e04436eb3440c72fcbe19853ec30fd576a1--urw-base35-fonts-20200910.tar.gz
==> Downloading https://lilypond.org/download/source/v2.25/lilypond-2.25.14.tar.
Already downloaded: /Users/nathanwhetsell/Library/Caches/Homebrew/downloads/3fab9b898b80ac147aeb75d204c1e6da366cab20f95e64a55055f89a2686f79f--lilypond-2.25.14.tar.gz
==> Upgrading nwhetsell/lilypond/lilypond-unstable
  2.25.13 -> 2.25.1
==> ./configure --datadir=/opt/homebrew/Cellar/lilypond-unstable/2.25.14/share -
==> make
==> make install
==> make bytecode
==> make install-bytecode
==> Caveats
lilypond-unstable is keg-only, which means it was not symlinked into /opt/homebrew,
because this is an alternate version of another formula.

If you need to have lilypond-unstable first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/lilypond-unstable/bin:$PATH"' >> ~/.zshrc

For compilers to find lilypond-unstable you may need to set:
  export LDFLAGS="-L/opt/homebrew/opt/lilypond-unstable/lib"
==> Summary
🍺  /opt/homebrew/Cellar/lilypond-unstable/2.25.14: 454 files, 29MB, built in 44 seconds
==> Running `brew cleanup lilypond-unstable`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /opt/homebrew/Cellar/lilypond-unstable/2.25.13... (454 files, 29MB)
Removing: /Users/nathanwhetsell/Library/Caches/Homebrew/lilypond-unstable--2.25.13.tar.gz... (18.4MB)

What did you expect to happen?

The full version number of the formula to be displayed.

Step-by-step reproduction instructions (by running brew commands)

brew tap nwhetsell/lilypond
git -C $(brew --repo nwhetsell/lilypond) checkout c0cc594546d2667f4ec498c8ae9ed6aaf509a3f9
HOMEBREW_NO_AUTO_UPDATE=1 brew install lilypond-unstable
git -C $(brew --repo nwhetsell/lilypond) checkout main
brew upgrade lilypond-unstable

[MikeMcQuaid]

Cannot reproduce:

mikebook # brew upgrade lilypond-unstable                                                  
==> Downloading https://formulae.brew.sh/api/formula.jws.json
#=#=- #                                                                                              
==> Downloading https://formulae.brew.sh/api/cask.jws.json
#=#=- #                                                                                              
==> Upgrading 1 outdated package:
nwhetsell/lilypond/lilypond-unstable 2.25.13 -> 2.25.14
==> Fetching nwhetsell/lilypond/lilypond-unstable
==> Downloading https://github.com/nwhetsell/homebrew-lilypond/releases/download/lilypond-unstable-2.2
Already downloaded: /opt/workbrew/home/Library/Caches/Homebrew/downloads/a4adb36076d79d01ef065b9c904b0e7085b7557be98daba79c1a35d5fc2aede1--lilypond-unstable-2.25.14.arm64_sonoma.bottle.tar.gz
==> Upgrading nwhetsell/lilypond/lilypond-unstable
  2.25.13 -> 2.25.14 

• This issue's title and/or description do not reference a single formula e.g. brew install wget.

Please ensure you can reproduce this sort of things with multiple core formulae in future.

[nwhetsell]

@MikeMcQuaid Thank you for taking a look at this and for all your work on Homebrew.

I’m not sure why this wasn’t reproducible (sorry about that!), but having taken a closer look, the nature of (what seems to be) the issue suggests that it may not be possible to reproduce this with core formulae, because there is no core formula with a sufficiently long name. The fundamental issue appears to be that a string that contains a newline is passed to Tty.truncate, which then truncates the string as if it was too long for a terminal.

It looks like the affected upgrade message is printed here:

oh1 <<~EOS
  Upgrading #{Formatter.identifier(formula.full_specified_name)}
    #{version_upgrade} #{fi_options.to_a.join(" ")}
EOS

oh1 passes its argument to oh1_title here:

def oh1(title, truncate: :auto)
  puts oh1_title(title, truncate:)
end

oh1_title passes the title argument to Tty.truncate here:

title = Tty.truncate(title.to_s) if $stdout.tty? && !verbose && truncate == :auto

In this case, the title being truncated is

Upgrading nwhetsell/lilypond/lilypond-unstable
  2.25.13 -> 2.25.14 

That’s 68 characters (note the space character after the version number on the 2nd line). However, there are 5 more characters after Upgrading for the ANSI escape of green, and an additional 5 characters to restore text color at the end of the first line. With the newline at the end of the string, that brings the total to 79 characters:

Characters

Character index	ASCII code (decimal)	Character
0	85	U
1	112	p
2	103	g
3	114	r
4	97	a
5	100	d
6	105	i
7	110	n
8	103	g
9	32
10	27	ESC
11	91	[
12	51	3
13	50	2
14	109	m
15	110	n
16	119	w
17	104	h
18	101	e
19	116	t
20	115	s
21	101	e
22	108	l
23	108	l
24	47	/
25	108	l
26	105	i
27	108	l
28	121	y
29	112	p
30	111	o
31	110	n
32	100	d
33	47	/
34	108	l
35	105	i
36	108	l
37	121	y
38	112	p
39	111	o
40	110	n
41	100	d
42	45	-
43	117	u
44	110	n
45	115	s
46	116	t
47	97	a
48	98	b
49	108	l
50	101	e
51	27	ESC
52	91	[
53	51	3
54	57	9
55	109	m
56	10	LF
57	32
58	32
59	50	2
60	46	.
61	50	2
62	53	5
63	46	.
64	49	1
65	51	3
66	32
67	45	-
68	62	>
69	32
70	50	2
71	46	.
72	50	2
73	53	5
74	46	.
75	49	1
76	52	4
77	32
78	10	LF

A common terminal width is 80 characters (the default width in Tty), Tty.truncate truncates strings to have 4 fewer characters than the terminal width, so truncated strings typically have 76 characters. When the affected message is truncated to 76 characters, the last character (at index 75) happens to be the penultimate digit of the new version number, so it appears that the last digit is omitted.

[MikeMcQuaid]

@nwhetsell We'd review a PR to make the second line of the oh1 a plain old puts instead (the first line should continue to use oh1 and be truncated when necessary.

[apainintheneck]

That’s 68 characters (note the space character after the version number on the 2nd line). However, there are 5 more characters after Upgrading for the ANSI escape of green, and an additional 5 characters to restore text color at the end of the first line. With the newline at the end of the string, that brings the total to 79 characters:

Ideally we wouldn't count non-printable characters when deciding where to truncate strings but that's not the main issue here.