I am trying to setup a two (maybe more) mailboxes in mutt with very different settings.
I have setup folder-hooks for each but it custom settings are not fully the same.
I wonder how to reset all custom settings setup for one mailbox before applying settings from the other.
The setup is:
.muttrc:
some custom config...
mre custom config...
folder-hook home source .mutt/home.config
folder-hook work source .mutt/work.config
I'd like to reset all configs setup by home.config when I apply work.config (but keep general config setup by .muttrc so reset all is too much).
You need
folder-hook . source .mutt/default.config
before the other two folder-hooks, as stated in section 3.5 of the manual.
Own answer:
Create a script reset.sh like:
grep -E -h -v '^(#.*)?$' $# | sed -E 's/(.*)=.*/\1/; s/^(un)?set/reset/g; /macro/d'
and as Adam suggested, in the main conf:
set my_reset_source=`~/.mutt/reset.sh ~/.mutt/*.config > /tmp/mutt-reset`
folder-hook . source /tmp/mutt-reset
folder-hook home source ~/.mutt/home.config
folder-hook work source ~/.mutt/work.config
Related
Right now, I'm trying to build a tool from source and use it to build a C++ project. I'm able to extract the tar file (gcc-arm-none-eabi). But, when I try to add it to path (using $GITHUB_PATH, not add-path), the path doesn't apply on my next action and I can't build the file. The error states that it can't find the gcc-arm-none-eabi toolset, which means that it didn't go to path.
Here's the script for the entrypoint of the first function (make is ran in the next action to allow for path to apply)
echo "Downloading ARM Toolchain"
# The one from apt isn't updated so I have to build from source
curl -L https://developer.arm.com/-/media/Files/downloads/gnu-rm/10-2020q4/gcc-arm-none-eabi-10-2020-q4-major-x86_64-linux.tar.bz2 -o gcc-arm-none-eabi.tar.bz2
tar -xjf gcc-arm-none-eabi.tar.bz2
echo "/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin" >> $GITHUB_PATH
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
I can't even debug by seeing what's in the path because running echo $(PATH) just says that PATH cannot be found. What should I do?
First, PATH is not a command so if you want to print its value, it would be something like echo "${PATH}" or echo "$PATH"
Then, if you want to add a value to an existing environment variable, it would be something like
export PATH="${PATH}:/github/workspace/gcc-arm-none-eabi-10-2020-q4-major/bin"
EDIT: seems not a valid way to add something to the path using Github Actions, meanwhile it seems correct in the question. To get more details: https://docs.github.com/en/free-pro-team#latest/actions/reference/workflow-commands-for-github-actions#adding-a-system-path . Thanks to Benjamin W. for pointing this out in the comments.
Finally I think it would be a better fit if you use a docker image that already contains that kind of dependancies (you could easily write your own Dockerfile if this image doesn't already exists). Github action is designed to use docker (or OCI containers) image that contains the dependancies you need to perform your build actions. You should take a look here: https://docs.github.com/en/free-pro-team#latest/actions/creating-actions/dockerfile-support-for-github-actions
I'm the author of a utilty that makes compressing projects using zip a bit easier, especially when you have to compress regularly, such as for updating projects submitted to an application store (like Chrome's Web Store).
I'm attempting to make quite a few improvements, but have run into an issue, described below.
A Quick Overview
My utility's command format is similar to command OPTIONS DEST DIR1 {DIR2 DIR3 DIR4...}. It works by running zip -r DEST.zip DIR1; a fairly simple process. The benefit to my utility, however, is the ability to use a predetermined file (think .gitignore) to ignore specific files/directories, or files/directories which match a pattern.
It's pretty simple -- if the "ignorefile" exists in a target directory (DIR1, DIR2, DIR3, etc), my utility will add exclusions to the zip -r DEST.zip DIR1 command using the pattern -x some_file or -x some_dir/*.
The Issue
I am running into an issue with directory exclusion, however, and I can't quite figure out why (this is probably be because I am still quite the sh novice). I'll run through some examples:
Let's say that I want to ignore two things in my project directory: .git/* and .gitignore. Running command foo.zip project_dir builds the following command:
zip -r foo.zip project -x project/.git/\* -x project/.gitignore
Woohoo! Success! Well... not quite.
In this example, .gitignore is not added to the compressed output file, foo.zip. The directory, .git/*, and all of it's subdirectories (and files) are added to the compressed output file.
Manually running the command:
zip -r foo.zip project_dir -x project/.git/\* -x project/.gitignore
Works as expected, of course, so naturally I am pretty puzzled as to why my identical, but dynamically-built command, does not work.
Attempted Resolutions
I have attempted a few different methods of resolving this to no avail:
Removing -x project/.git/\* from the command, and instead adding each subdirectory and file within that directory, such as -x project/.git/config -x project/.git/HEAD, etc (including children of subdirectories)
Removing the backslash before the asterisk, so that the resulting exclusion option within the command is -x project/.git/*
Bashing my head on the keyboard in angst (I'm really surprised this didn't work, it usually does)
Some notes
My utility uses /bin/sh; I would prefer to keep it that way for maximum compatibility.
I am aware of the git archive feature -- my use of .git/* and .gitignore in the above example is simply as an example; my utility is not dependent on git nor is used exclusively for projects which are git repositories.
I suspected the problem would be in the evaluation of the generated command, since you said the same command when executed directly did right.
So as the comment section says, I think you already found the correct solution. This happens because if you run that variable directly, some things like globs can be expanded directly, instead of passed to the command. And arguments may be messed up, depending on the situation.
Yes, in that case:
eval $COMMAND
is the way to go.
My project structure is:
I want user additionally to configure the build using some of the build scripts from specifications dir but the main build script to be used to configure the project as well. Using -b option give the ability to specify another build scrpt different from the default one, but I want this default one to be executed as well. I don't want to use apply from: and to add all scripts because user have to decide what he wants.
So is there a way to tell Gradle to add additional build script - command line with which to configure extra the Project?
If you need this this, you could do something like this:
apply from: "config/specifications/${project.spec}.gradle"
which would then allow users to do e.g.
./gradlew -P spec=example
See https://docs.gradle.org/current/userguide/build_environment.html#sec:gradle_properties_and_system_properties for more details on setting project properties from the command line.
I've done some research, but honestly can't seem to figure this out.
You can set some set some options to have fossil extras ignore files, but not fossil add? The configuration options through the web interface is great, and I'm pleased that it does work for the extras command, but it doesn't apply to the add command?
How does one configure fossil to ignore files on fossil add .?
You can use the settings ignore-glob command to list the directories/files to ignore as a comma-separated list.
On your repository's web interface, go to the Admin menu, select Settings and type the comma-separated list of directories to ignore; for example: */*.suo,*/*/bin/*,*/*/obj/*.
Alternatively, on the command line you can type fossil settings ignore-glob to list the applied ignore list, or fossil settings ignore-glob list-of-files.
You can also create/edit the .fossil-settings/ignore-glob at the root of the project and insert the comma-separated list of files/directories to ignore; I have not personally tested this, but I remember reading this online.
For example, on the command line you can do:
fossil settings ignore-glob "*/*.suo,*/*/bin/*,*/*/obj/*"
This would ignore all .suo files in every subdirectory at the Fossil repository root tree, and all the files in the bin and dir subdirectories at the each of the directory in the root directory.
If you want something like .gitignore or .hgignore, you can read https://www.fossil-scm.org/index.html/doc/tip/www/settings.wiki
mkdir .fossil-settings
echo '*/*.suo' >> .fossil-settings/ignore-glob
echo '*/*/bin/*' >> .fossil-settings/ignore-glob
fossil add .fossil-settings
See this check-in in fossil development repository. What you asked for has been implemented.
very recent versions of Fossil have an addremove command that will add all extras and remove all missing files in your working tree. The --ignore-glob switch is available.
Perhaps this is what you are looking for?
Otherwise you could probably just do :
fossil extras | xargs fossil add
On Windows 7 (not tested on other platforms)
If you do
fossil add *.*
All ignore-glob settings are ignored (all files are added).
If you do
fossil add .
then ignore-glob settings are used.
It is because I have already added the file, and fossil skipped the duplicated "add" operation, OMG.
I run django-admin makemessages -l ro -e html,txt,rml in the application's directory (above the locale directory) to generate the PO files. When I open a PO file with Poedit, e.g. locale/ro/LC_MESSAGES/django.po, I can not see where the message is being referenced. The paths from the catalog look like this:
#: admin.py:12 admin.py:23
so Poedit tries to open locale/ro/LC_MESSAGES/admin.py which of course does not exist.
Update:
find -path '*/locale/ro/LC_MESSAGES/django.po' -exec sed --in-place -r '/^#: / s/([a-zA-Z_./]+):([0-9]+)/..\/..\/..\/\1:\2/g' {} \+
fixes the paths, but I would still like to see this problem solved at its core.
I've also reported this on Django's bug tracker.
See the poedit-users mailing list thread (yes, that was the best place to ask).
Update: ​Poedit handles this case correctly since version 1.5.6.