Shellcheck fixes

[aplanas]

No description provided.

[laenion]

I know that it's a draft, but in it's current form this PR doesn't make a lot of sense. It looks like an automated script just changed things without any understanding of the code.

It's not that these changes would be incorrect per se, but after reading almost half of the patch I haven't seen a single line where this patch would actually fix something (except maybe the exit on failed pushd / popd commands: It's just changing the syntax from one style to another style. And worse, it also adds random comments into the source code...

So in other words: Some commits are indeed useful (such as removing unused variables / functions), most of change simply don't change anything except for the syntax, and some of them are totally random...

[aplanas]

It looks like an automated script just changed things without any understanding of the code.

I am using shellcheck to identify groups of issues, as I expect to use it later. Was extremely useful to find bugs in bash.

half of the patch I haven't seen a single line where this patch would actually fix something

If you run shellcheck for bash on this code you will have 201 detected issues (errors and warnings). Removing those is helping to identify real problems:

• Is SHELL_CMD forgot to be used in the tukit call bash, or is an old code?
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L954

• rebootmethod is never declared nor initialized, comes from a source configuration file? If not, then the condition will always be true
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L1719

• Why this is iterating for only one element?
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L1172

There are more, like some missing quotes that can produce word splitting, and other stuff, but to reach the real issues you cannot navigate thru hundreds on elements in the report.

And worse, it also adds random comments into the source code...

Those are shellcheck commands ...

and some of them are totally random...

Can be ... can you point me one?

[aplanas]

and some of them are totally random...

Can be ... can you point me one?

To extend on this, I know that I make some stylistics changes (! -z instead on -n), but others are real issues:

• $() instead of backtick: https://www.shellcheck.net/wiki/SC2006
• Separate declaration from initialization when calling a function: https://www.shellcheck.net/wiki/SC2155
• Use && || instead of -a -o: https://www.shellcheck.net/wiki/SC2166

It is OK to drop this, but then I recommend you use shellcheck and navigate into the reported elements and evaluate then case by case: there are real bugs.

[laenion]

and some of them are totally random...

Can be ... can you point me one?

Just look at the first 6 changed lines in https://github.com/openSUSE/transactional-update/pull/120/files: 5 of them are adding a comment without changing anything. These comments either seem to be a TODO, the other ones don't even explain what they want to say, so I wouldn't call that helpful for someone trying to understand the code.

Or look at changes such as in line 340 - they simply won't do anything, it's not even a stylistic change.

Some of them are also inconsistent, like the one in line 742 - shouldn't it include both variables into the quotation marks?

To extend on this, I know that I make some stylistics changes (! -z instead on -n), but others are real issues:

* $() instead of backtick: https://www.shellcheck.net/wiki/SC2006
* Separate declaration from initialization when calling a function: https://www.shellcheck.net/wiki/SC2155
* Use && || instead of -a -o: https://www.shellcheck.net/wiki/SC2166

How are these issues in the context of this script?

It is OK to drop this, but then I recommend you use shellcheck and navigate into the reported elements and evaluate then case by case: there are real bugs.

You are implying that the code is currently full of bugs, but after a quick review the only potential issue I've seen is not catching the return value when changing directories.

I guess your strategy is to make shellcheck happy now so that potential problems in the future will be more visible? In general I'm fine with this, but to be honest I'm not really happy about the fact that the tool is generating so many false positives / enforcing code that isn't changing anything.

[laenion]

If you run shellcheck for bash on this code you will have 201 detected issues (errors and warnings). Removing those is helping to identify real problems:

* Is SHELL_CMD forgot to be used in the tukit call bash, or is an old code?
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L954

Indeed, using that parameter seems to have been lost somewhere.

* rebootmethod is never declared nor initialized, comes from a source configuration file? If not, then the condition will always be true
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L1719

I think this should have been changed to REBOOT_LEVEL.

* Why this is iterating for only one element?
  https://github.com/openSUSE/transactional-update/blob/master/sbin/transactional-update.in#L1172

It was reusing the pattern from the other SETUP_ commands and could easily be extended if more packages were needed.

There are more, like some missing quotes that can produce word splitting, and other stuff, but to reach the real issues you cannot navigate thru hundreds on elements in the report.

As I said: It's not that I'm opposing the changes, but it is a real problem that the script is generating so many false positives.

[aplanas]

and some of them are totally random...

Can be ... can you point me one?

Just look at the first 6 changed lines in https://github.com/openSUSE/transactional-update/pull/120/files: 5 of them are adding a comment without changing anything. These comments either seem to be a TODO,

Yes. It is a reminder for me that I need to convert those variables from strings to array, so tukit ${TUKIT_OPTS} can be resolved to tukit "${TUKIT_OPTS[@]}" and the # shellcheck disable=SC2086 comments can be dropped. Is just this: a TODO reminder for me.

the other ones don't even explain what they want to say, so I wouldn't call that helpful for someone trying to understand the code.

It is a shellcheck directive, they are explained here: https://www.shellcheck.net/wiki/Directive

Or look at changes such as in line 340 - they simply won't do anything, it's not even a stylistic change.

Not sure why you say that: it is adding quotes to ${NEW_DEFAULT_SNAPSHOT_ID}.

Some of them are also inconsistent, like the one in line 742 - shouldn't it include both variables into the quotation marks?

No. ${SNAPSHOT_DIR} changes, so the content is not known and can contain spaces: needs to be under quotes. But ${STATUS_FILE} is constant, and shellcheck is detecting that did not change and does not contain quotes. It is not inconsistent, it is a correct change.

Of course it is also OK to move all between quotes, but because shellcheck proves that only one part varies, it is recommended to do that explicitly.

To extend on this, I know that I make some stylistics changes (! -z instead on -n), but others are real issues:

* $() instead of backtick: https://www.shellcheck.net/wiki/SC2006
* Separate declaration from initialization when calling a function: https://www.shellcheck.net/wiki/SC2155
* Use && || instead of -a -o: https://www.shellcheck.net/wiki/SC2166

How are these issues in the context of this script?

They are issues in all bash scripts. Please, read the links. For example, for SC2155 will make some trap to fail, and if we move to set -e this will cause further problems.

SC2166 is more clear: using -a or -o is even advised not to do by POSIX.

It is OK to drop this, but then I recommend you use shellcheck and navigate into the reported elements and evaluate then case by case: there are real bugs.

You are implying that the code is currently full of bugs, but after a quick review the only potential issue I've seen is not catching the return value when changing directories.

No, not at all. I am implying that there are real bugs that can automatically detected but we cannot see that easily: dead code, or live variables that seems to be not initialized maybe breaking a long boolean expression.

I guess your strategy is to make shellcheck happy now so that potential problems in the future will be more visible?

And in the present. Please, review the comment #120 (comment) I pointed three that I did not fixed here.

In general I'm fine with this, but to be honest I'm not really happy about the fact that the tool is generating so many false positives / enforcing code that isn't changing anything.

I am sorry, but they are not false positives. You know very well that bash is a tricky language that is sadly full of corner cases. All those elements appointed by the tool are pointing to hidden bombs that can trigger later.

For example, you yourself quoted "${SNAPSHOT_ID}", but you expect that will always be a number. You quote that just because is this changes, or a bug is later introduced that make it a string with spaces, something dangerous can happen. Those changes are on the same line.

[aplanas]

As I said: It's not that I'm opposing the changes, but it is a real problem that the script is generating so many false positives.

There is no single false positive in the report.

[aplanas]

Note: last POSIX 2024 removed -a -o: https://sortix.org/blog/posix-2024/