Auto-mount boot (and several recipe cleanups) #245
Conversation
|
|
||
| case "${fbcon}" in | ||
| "rotate:3") | ||
| case "`cat /sys/class/graphics/fbcon/rotate`" in |
There was a problem hiding this comment.
please use new-style subshell syntax $(..) and avoid this "useless use of cat" by using
$(</sys/class/graphics/fbcon/rotate)
There was a problem hiding this comment.
That's a bashism, isn't it?
There was a problem hiding this comment.
The redirect is, and we seem not to be using bash here.
But the command substitution should nevertheless be in $()
There was a problem hiding this comment.
Because the `` form is only supported due to backward compatibility. $() is POSIX and current day syntax.
There was a problem hiding this comment.
From the same document: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_06_03
"Because of these inconsistent behaviors, the backquoted variety of command substitution is not recommended for new applications that nest command substitutions or attempt to embed complex scripts."
More clear here in the BashFAQ:
https://mywiki.wooledge.org/BashFAQ/082 :
... is the legacy syntax required by only the very oldest of non-POSIX-compatible bourne-shells. There are several reasons to always prefer the $(...) syntax:
https://guide.bash.academy/expansions/?=Command_Substitution#p1.3.0_7
"As a closing note, I will make brief mention of the deprecated ... syntax. Old-style bourne shells used this syntax for Command Substitution instead of the more modern $(...) syntax. In bash and all modern POSIX shells, both syntaxes are supported, but it is highly recommended that you stop using the backtick (`) syntax and change this syntax into the value-expansion equivalent whenever you see it used in the wild. Although they are functionally equivalent, the backtick variant has some very important downsides:
The backtick syntax looks a lot like quoting. This has caused widespread confusion among users. Even to the trained eye, it is sometimes hard to not forget that backtick expansions still need double-quotes around them to be safe, just like all other value expansions.
The backtick syntax is inconsistent with value expansions. The beauty of $(...) is that is clearly communicates that we are expanding a value into place here, just like all other dollar-style value expansions do. This clarity is absent with the backtick syntax.
The backtick syntax turns quoting and nesting into an exercise in absurdity. It requires a maze of backslash-escaping which makes it almost impossible to parse and nearly guarantees that you will make mistakes: echo "`echo \"\`echo \\"hello\\"\`\"`" vs. echo "$(echo "$(echo "hello")")"
Shellcheck will also complain:
https://github.com/koalaman/shellcheck/wiki/SC2006
There was a problem hiding this comment.
... that nest command substitutions or attempt to embed complex scripts
This precondition does not apply here. This is no nesting and no complex script.
This is not a bash script, so a bash FAQ is not relevant here.
There was a problem hiding this comment.
BASH is a BourneShell
... that nest command substitutions or attempt to embed complex scripts
This precondition does not apply here. This is no nesting and no complex script.
The point is to habitually not use this syntax at all.
Someone may copy or modify your code and not know the limitations / dangers.
This is not a bash script, so a bash FAQ is not relevant here.
Your escaping on technicalities here:
BASH is a BourneShell compatible shell, which adds many new features to its ancestor. Most of them are available in the KornShell, too. The answers given in this FAQ may be slanted toward Bash, or they may be slanted toward the lowest common denominator Bourne shell, depending on who wrote the answer.
There was a problem hiding this comment.
This is a POSIX shell script (/bin/sh), and neither bash nor bourne nor korn shell script. None of that is relevant.
You can say you prefer $() over backticks because you like it more, as a matter of personal taste, and the OpenVario project could even make it a coding style rule. All of that would be valid.
But you can't claim it's deprecated or only in POSIX for backwards compatibility, because that's not true.
There was a problem hiding this comment.
There is a lovely discussion on what deprecated in this context means here:
https://unix.stackexchange.com/questions/126927/have-backticks-i-e-cmd-in-sh-shells-been-deprecated
Backwards compatibility: If you add a new method to the standard, that eclipses all function of your old method, why would you keep the old function? The only reason is Backward compatibility.
|
It is part of the usual OpenVario distribution, just like XCSoar and anything else. There's no point in using |
It makes no sense to use two different recipes for this. If you install ovmenu-ng, it should contain the systemd unit, just like all other packages which provide systemd units.
…of /proc/cmdline This is simpler and more robust.
|
If you believe "disable SSH access by default" is debatable, I'll remove it from this PR and create a separate PR for discussing it. |
|
|
||
| [Mount] | ||
| What=/dev/mmcblk0p1 | ||
| Where=/boot |
There was a problem hiding this comment.
Would /etc/fstab entry be a simpler solution for this?
There was a problem hiding this comment.
Think we can change this afterwards as well, but it doesn't matter from my point of view ..
|
On 2022/02/04 21:06, Andrey Lebedev ***@***.***> wrote:
Would `/etc/fstab` entry be a simpler solution for this?
No. It may seem simpler because at first it's only one line, but
systemd mount units are more powerful, and managing fstab is hard,
while systemd mount units are self-contained and can just be added,
removed, updated etc.
|
No description provided.