Package: console-setup
Version: 1.225
Severity: grave

After the upgrade from 1.223, console-setup.service failed to start
due
to a syntax error in the setupcon script:

,----
| $ setupcon
| /usr/bin/setupcon: 1386: Syntax error: Missing '))'
`----

It looks like dash does not like the construct in line 907 where
there
is an opening '$((' but the closing parentheses are split.

,----
| $ dash << 'EOF'
| > echo $((true))
| > echo $((true) )
| > EOF
| 0
| dash: 3: Syntax error: Missing '))'
| $
`----

I tried

dash << 'EOF' [15:28:53]
if $( (true) 2>/dev/null); then
echo "42"
fi
EOF
42

which only works in dash because of the added space between the
command substitution $(...) and the subshell (...).

Does dash think it has to do arithmetic expansion "$((...))"?

bash and zsh in sh mode accept nesting a subshell within the command substitution without an extra space. In the last version of the
script, backticks were used, circumventing this issue.

But what's POSIX take on this? I couldn't find anything. Is this a
bug in dash or in setupcon?

Toto

PS: To the proposal of a cleanup: 'checkbashisms' doesn't return any
errors, but IMHO, at least closing (double) quotes on
a line of their own should be fixed:

$ cat /bin/setupcon | grep -n "^\(\"\|'\)$"
[15:47:07]
87:'
145:"
148:"
190:"
193:"
208:"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thorsten Bonow <toto@not-in-kansas-anymore.org> writes:

[...]

But what's POSIX take on this? I couldn't find anything. Is this a
bug in dash or in setupcon?

I'm stupid[1]. It's a bug in setupcon, POSIX requires the space:

"The syntax of the shell command language has an ambiguity for
expansions beginning with "$((", which can introduce an arithmetic
expansion or a command substitution that starts with a subshell.
Arithmetic expansion has precedence; that is, the shell shall first
determine whether it can parse the expansion as an arithmetic
expansion and shall only parse the expansion as a command substitution
if it determines that it cannot parse the expansion as an arithmetic
expansion. The shell need not evaluate nested expansions when
performing this determination. If it encounters the end of input
without already having determined that it cannot parse the expansion
as an arithmetic expansion, the shell shall treat the expansion as an incomplete arithmetic expansion and report a syntax error. A
conforming application shall ensure that it separates the "$(" and '('
into two tokens (that is, separate them with white space) in a command substitution that starts with a subshell. For example, a command
substitution containing a single subshell could be written as:

$( (command) )"


Footnotes:
[1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Tokarev <mjt@tls.msk.ru> writes:

09.02.2024 16:58, cacin@allfreemail.net

Package: console-setup
Followup-For: Bug #1063518

Consider making all scripts provided by console-setup
shellcheck-clean, there are lots of tiny issues that can turn into
big issues under the right conditions.

Please do not do this. Shellcheck is a huge problem and we had large amount of bugs due to people trying to apply its suggestions. It's very difficult in many cases to spot why shellcheck is wrong (classic is the suggestion to put $var into double quotes "$var" which breaks badly if $var is supposed to contain zero or more separate words - this way, even boot scripts has become buggy leading to system becoming unbootable).

Shellcheck is a very bad tool.

I think the reality is somewhere between these two positions.

Shellcheck is not particularly helpful for most of D-I because it
doesn't have a shell variant that perfectly matches our busybox sh
build. That might have just improved, since I notice that a busybox sh
variant has just been merged upstream, so we'll see if that makes things better.

On the other hand, if I'd been paying attention at the time, the fact
that this change dropped the number of shellcheck reports for setupcon
from 189 to 1 should have rung some alarm bells, but it seems that I've
learnt to ignore the little '!' in my emacs status bar -- I'll have to
keep an eye on that in future.

Cheers, Phil.
--
Philip Hands -- https://hands.com/~phil

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)