-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Suggestion] Is it possible to control forced loading of "~/.avrduderc"? #1548
Comments
Maybe a command-line-option is useful, eg, It is generally not a great idea to tweak the avrdude.conf file so that AVRDUDE changes its behaviour to support unknown/unsupported projects, platforms or programmers. I hear that a few projects do this, eg, some of @SpenceKonde's cores. They then are at risk of being surprised if further development of AVRDUDE breaks some of the tweaky artificial behaviour that AVRDUDE had no idea was being utilised to tell bootloaders or programmers about some property. Generally, it is best to get the code base of AVRDUDE work with the project. The idea of the avrdude.conf file is to externalise a parameter model of programmers and parts that match with the code base. In general, the system-wide avrdude.conf file should not be modified. The personal ~/.avrduderc file is meant as a means to add own programmer parameters (for example, if one rigs an FTDI chip with a certain pin mapping to the I2C signals PICO, POCI, SCK and AVR Reset) or new parts that the system-wide avrdude.conf file does not yet know about. Enabling a system-wide configuration file to override and switch off the user's personal configuration is questionable. In my world, this is firmly something that the user should decide, not another configuration file. |
I do not know that! Because Usage currently doesn't have that. And "-?" seems to be broken in zsh.
If you think about it, Usage is pretty unkind right now. PM_PDI/PM_UPDI etc. can be confusing as some options can and cannot be used with other options. To filter help messages, the implementation must be modified to allow |
When using "avrdude" in the backend of the Arduino IDE, the end user never touches the command line. Sketch builds also do not include make files. Simply choose from the options that appear in the IDE's menus. Usually only the choices that have been vetted for that project are available. User-defined avrduderc files can override that behavior. However, adding a new However, it would be useful in the future if implementations like "serialupdi", which have many unknown variants, could be controlled by user-defined avrduderc files. |
| Usage currently doesn't have [ Correct. That's because I suggest implementing | When using "avrdude" in the backend of the Arduino IDE, the end user never touches the command line. Correct. The Arduino IDE controls the command line and could use | zsh: no matches found: -? Well, zsh interprets wildcard characters such as | [programming modes] the implementation must be modified to allow -c Programmer and -p part to be specified together Well, if a programmer only can handle UPDI parts and it is specified with a part that cannot be programmed through UPDI, then AVRDUDE warns the user and offers to try nevertheless using
But yes, if you find an error in the programming mode specification, please raise an issue. Also note that programmers that serve bootloaders can and should specify |
All right, I understand.
Please implement it. In the future I can change the programmers.txt project configuration to allow '-N' via the preferences.txt user configuration.
suggestion. Can Usage be changed to '-h' according to common *UNIX programming practice? Fortunately, '-h' currently appears to be unused. For the time being, '-?' can be considered equivalent to '-h'. This probably resolves my concerns. |
Indeed this may be a good improvement. @stefanrueger
|
Do you really want to change 23-year old behaviour of AVRDUDE that was perfectly fine and accepted all those decades? At the time everyone was using |
Probably not to change, but just to add BTW, indeed people use Windows CMD prompt still uses |
(Of course this is my personal opinion) "?" Certainly a traditional help command character from before CP/M. However, back then each command implemented its own wildcard and metacharacter expansion (I remember writing it in MACRO80). COMMAND.COM was just a launcher, not a shell. At some point, the shell started treating them as metacharacters, and many symbols could no longer be passed to commands without escaping them. Nowadays, this has become commonplace, so when I found the "?", I felt a strange sense of nostalgia. That may be all. |
All shells I know shells do wildcard expansion on |
Tell that the getopt(3) library function, which actually prints it that way. This is a standard function that is often used and that's what it prints. I wouldn't have printed that this way either, but there you go. |
Perhaps zsh doesn't behave the way you know.
Why did Apple kill bash and make this damn shell the standard? Not at all. . . |
By the way, zsh does not pass a simple "?". Even if it's in the middle of a string.
'?' in zsh is a ternary operator. The error is thrown because the ':' pair is missing. I have a headache. |
| zsh: no matches found: -v?v Try Different shells have different default behaviour if there are no files that match wildcards: tcsh and zsh say No matches found. Bash by default passes any wildcard expression on if no matching file could be expanded. Both default behaviours can be changed by the user. |
In this case, that customization certainly makes sense. I don't like changing the user environment and ideally would like to keep everything as factory as possible. (In my job) I always make sure that all test results are reproducible. Even Emacs hasn't been fixed. So I decided to stick to my guns and accept the inconvenience. Thank you for your advice. |
It's quite normal that you have to quote special chars to the shell, ? and * belong to them. I always considered the Bourne-shell (and thus bash) behaviour quite inconsistent: if you have something where * or ? could expand filenames to, they expand it, otherwise they pass it literally. Thus, the actual behaviour depends on the contents of your current directory – which I think is not really a Good Thing. |
Btw., they didn't "kill" it. Just as in any Unix, you can simply use "chsh" to change your shell to one you'd like. |
This proposal is somewhat related to the following requirements:
Please ignore if it is deemed unnecessary.
Background of the problem
As mentioned in the following comment, multiple board support projects that can be integrated into the Arduino IDE use different versions of "avrdude".
They can be installed at the same time and use their own configuration files so that they do not interfere with each other.
Unfortunately, "~/.avrduderc" is not. There are always no or only one user-defined file. Therefore, it is always read from different versions of "avrdude" and the content that can be written differs depending on the version, so it always stops with an error.
In conclusion, the use of "~/.avrduderc" is not recommended for anyone using the Arduno IDE.
However, in that case, users may install their own "avrdude" on the OS and create "~/.avrduderc", causing various problems. This cannot be called orderly.
Suggestions or ideas
Is it possible to add the following global switch at the beginning of the new "avrdude.conf"?
If this is "no", "~/.avrduderc" will not be read and will be ignored. This should prevent problems.
The default is "yes", which is the legacy compatible behavior. However, if related projects are aware of this issue, they can choose "No" in their own configuration files and distribute them.
Projects that are no longer updated or are unlikely to be updated will not be able to support this improvement and will continue to use the old "avrdude". However, we should be able to consider ongoing projects (unless it is difficult due to individual circumstances).
I'm not yet familiar enough with all of the project's source code to modify it myself, so I don't know if that's possible.
We look forward to hearing your frank opinions.
The text was updated successfully, but these errors were encountered: