pacaur should use --asdeps for AUR dependencies #548
Comments
|
I cannot reproduce: Are you sure the |
|
Apologies, I've omitted a crucial bit of information from my initial report. The problem only occurs when using Full log: https://dump.thecybershadow.net/e85ff01ce1a09dfc09fb35b0c5fbc940/17%3A52%3A06-upload.txt
Hmm, this list is formatted differently for me. Is this due to a setting or something else? |
|
Confirmed. Will have a look right now.
See Notes section in man page. |
|
Fixed in fc420a0. The issue occured because |
|
Thanks. By the way, is there a reason why pacaur doesn't use |
|
Because it's bad practice. |
|
Sorry, but is that actually true? On the page you linked, there are two recommendations from two persons, out of which one is for and one is against Looking at the first page of https://www.google.com/search?q=bash+set+e+practice , the overwhelmingly popular opinion is that Either way, wouldn't Correct me if I'm wrong, but this very bug would've likely been caught much sooner with |
|
Feel free to send a pull request that handle all the caveats - I have no time to deal with such broken command. |
|
@CyberShadow Google is about the worst source for bash advice. Anyway |
That's a good thing. Just like uncaught exceptions will stop the entire program in any modern programming language.
I guess we'll have to disagree on this.
I've been using it with great success in the project I'm currently working on. I think its quirks can be boiled down to a few simple rules of thumb. Since my last comment, I've researched the subject a bit more, and have come to the conclusion that not using |
|
Maybe in an utopic world; in practice you'll have all sorts of commands return non-zero even when no "exception" occurred. Add to that how irrational behavior with A more sensible method is to write your script so that you don't have to rely on quirky methods like Anyway I have no interest in painting the bikeshed about this; as said, if you find some bug that's only visible with |
This is trivially handled using e.g.
Are you talking about commands randomly (i.e. sometimes) returning a non-zero status, when nothing went wrong? If so (and putting aside that by itself that sounds like a bug in said command), do you really think that's more fun to debug than your script going haywire once in a blue moon because some command randomly failed, and you forgot to check its exit status? Or are you talking about them doing it consistently (in which case, it's part of the normal functioning of the script and handled as above)?
That's pretty vague, would you care to elaborate? If you mean adding the equivalent of
I hope we can agree that shell scripting is quirky in nature in general, which is why ShellCheck is indispensable.
Honestly, me neither; I considered the conversation over with rmarquis' last comment. |
|
As far as I've understood, the bottom line is that if your script does not use
and is therefore buggy by design. |
If you know where to look, sure.
For example, if you only want to download part of a file with
Things like using the right if clauses; you're only going to continue logic if certain conditions are met. As I said, if you just batch a series of simple commands and want to "|| die" on any one of them, then set -e works. If you're going for more complex logic, set -e will behave in unexpected ways (i.e., not catch errors where they did in fact occur) and you wish you've gone all the way and came up with your own mechanisms to catch errors.
That's another issue for that: #460. Maybe you can assist with it. |
The same applies to finding the source of random failures, which, given that they may not be trivially reproducible, can be much harder to find.
I don't understand this example. Is
Yes, this sums up |
Except if you put in the effort of properly structuring your code and project as a whole it wouldn't be. It's almost as if we're arguing about programming in C! 😄
That doesn't matter; fact is it's the normal operation of the script. Cutting off curl in the middle of an operation isn't very nice, but in some cases that's what you're stuck with.
Well, if the argument is "don't do anything non-trivial in Bash", then you could perhaps rewrite pacaur in Python... |
This phrase has appeared a few times in this conversation but I'm still not sure what exactly it means :) The only thing I can think about is explicit checks around everything, which doesn't change that the code is buggy by default and you have to meticulously add mountains of boilerplate everywhere to make it correct.
Funny you should say that :) Because the typical "hello world" program in C is, in fact, incorrect.
Sorry, I still don't understand what you mean here :(
Sorry, that's not what I meant. For example, don't do this: if [[ "$(command)" == "expected-output" ]] ; then ...Instead, do this: local command_output
command_output="$(command)"
if [[ "$command_output" == "expected-output" ]] ; then ...This will make your script correctly fail if MyFunction || true # it's OK if the function failsThis will cause each individual command in |
With more complex code you'll need "boilerplate" anyway, for example to check if variables are set, if files were created, etc., because of set -e being unreliable. That's my main objection; to write scripts under the assumption that set -e will reliably detect errors. If you make sure that your script handles errors reliably, and that you are able to check intermediary results reliably (for example, by keeping them in temporary files) even without set -e -- besides being aware of programs that may return non-zero -- then by all means, add set -e as an extra layer of protection. For your example, I do agree shellcheck should warn there for possibly lost exit codes, if it doesn't already. Anyway, I've probably drifted this thread off-topic enough already. :) |
I think "unreliable" is not a good word to describe it, since (unlike the error conditions I listed above) it can't fail unpredictably. Its behavior is predictable, which means that it can be used correctly. I think we just need better tools (like ShellCheck) to enforce this.
I think this is the wrong way to go about things. Strictly theoretically, correctness does not come in layers, it is binary - a program is correct or not. For example:
What if disk space runs out halfway while the file is being written? (If not disk space, there's the I/O cgroup limit which causes processes exceeding that limit to be killed...)
If the data for the variable comes from a file or program, the same problem occurs. In most cases, there is no way to completely verify that a program executed correctly, because to fully verify that you would need to repeat the task done by the program yourself and compare the results. Error reporting is the only truly reliable way to ensure your script fulfills its contract. If error reporting and propagation in your program is correct (and putting aside possible bugs in other components), then additional simplistic checks that the results are as expected are redundant. |
|
Well, knock yourself out: http://www.fvue.nl/wiki/Bash:_Error_handling |
|
Thanks. I'm already familiar with much on that page. It seems somewhat outdated, since I can no longer reproduce their "Caveat 1". I guess I should add a bash version check to my script. |
|
When you guys are finished fighting, please send PR if you want to improve this aspect of pacaur. |
It seems that currently, when installing AUR dependencies for requested AUR packages,
pacaurdoes not use--asdeps.For example, attempting to install
enigma-dev-gitpulls in these dependencies:After installation, querying the database reveals that all installed AUR packages have the installation reason as "explicitly installed", and not just the one explicitly requested:
This is with pacaur 4.6.8.
The text was updated successfully, but these errors were encountered: