After switching the Linux Distributions, gpg changed and I could not encrypt any emails. Even my own. Enigmail gave me "No matching secret key found to decrypt message" error message.
Before:
$gpg --version
gpg (GnuPG) 2.1.18
libgcrypt 1.7.6-beta
Now:
$gpg2 --version
gpg (GnuPG) 2.2.13
libgcrypt 1.8.4
Both have Enigmail 2.0.9.
It's been long time since you wrote. Nevertheless I'd try to give it a chance, as I think similar problem still might happen (again).
First of all try this command:
gpg-agent --daemon
Expectation is, it would show you if something is wrong with config file(s). Example output:
gpg-agent[22861]: /home/<REPLACE_WITH_YOUR_USERNAME>/.gnupg/gpg-agent.conf:13: invalid option
This, for example, is telling you: "Line 13 in that file contains invalid setting option".
In this case, edit that file, remediate the error or comment out the line creating the error for example like this:
Edit the file. Example, in your console/terminal, try one of this:
nano /home/REPLACE_WITH_YOUR_USERNAME/.gnupg/gpg-agent.conf
gedit /home/REPLACE_WITH_YOUR_USERNAME/.gnupg/gpg-agent.conf
editor /home/REPLACE_WITH_YOUR_USERNAME/.gnupg/gpg-agent.conf
now go to that line (here in the example it is line 13), and replace its content, example
ignore-caching-for-signing
with the line
# ignore-caching-for-signing
Plsease note the '#' in front of the line, which is the comment sign to deactivate the invalid option.
Go to line 1. above and repeat the gpg-agent command, and the steps up to this line, until the gpg-agent starts without complaining about invalid options
gpg-agent --daemon
Now start thunderbird with enigmail, and click on the encrypted mail. From my experience, you should now be able to see its content.
In the end, this helped: https://sourceforge.net/p/enigmail/forum/support/thread/03ebee57/
gpg2 --edit-key 0xYourKeyId setpref save
(0xYourKeyId taken from gpg2 --list-secret-keys)
EDIT: ok, this does not work. I can decrypt messages for like 5 minutes since I had to unlock the keychain in the dialog.
Related
This question already has an answer here:
how to fix "bash: flutter: command not found" error?
(1 answer)
Closed 2 years ago.
I have read through a lot of posts regarding command not found error messages in the terminal but I can't find any specific to surge.
I am running into an error when using the surge command in my terminal. I ran npm install --global surge in my terminal and everything looks okay, but when I run the command surge it returns command not found.
The other npm packages on my computer work fine. I tested create-react-app and no errors. I am somewhat new to this, any advice would be appreciated!!
Thanks and cheers!!
Just use npx surge instead of surge
:)
Are you sure surge executable is installed?
what shell are you in?
If in bash, try re-hash-ing:
hash [-lr] [-p filename] [-dt] [name]
Each time hash is invoked, the full pathname of the command name is determined by searching the directories in $PATH and remembered.
Any previously-remembered pathname is discarded. If the -p option is supplied, no path search is performed, and filename is used as
the full filename of the command. The -r option causes the shell to forget all remembered locations. The -d option causes the shell
to forget the remembered location of each name. If the -t option is supplied, the full pathname to which each name corresponds is
printed. If multiple name arguments are supplied with -t, the name is printed before the hashed full pathname. The -l option causes
output to be displayed in a format that may be reused as input. If no arguments are given, or if only -l is supplied, information
about remembered commands is printed. The return status is true unless a name is not found or an invalid option is supplied.
There is a chance that the surge binary is missing from your terminal's current PATH. To check if that is the case, locate where is the binary installed by default (in my machine is found under /usr/local/bin directory) and check if that directory is present in your PATH, by running:
echo $PATH
In case it is not, you can add it by running:
PATH=$PATH:/path/to/surge/location
Then check if it works now:
surge
If that's the case, to make this change persitent across reboots, you can echo the current PATH you have defined:
echo $PATH
And then export the result of that last command to your ~/.bashrc file, by adding this line:
export PATH=/previous/command/output/here
This question might be silly, and I think it is something so basic that I can't even find the solution because it might be obvious to everyone.
Here's the thing:
I want to download a file from mega.nz using bash.
I found this bash script on github: https://github.com/tonikelope/megadown/blob/master/megadown
I don´t know how to run this
Tried:
Copy-pasting the file to a file called "megadown.sh" and then running:
$ bash megadown.sh 'https://mega.nz/#F!BwQy2IAS!AwWpbCPzgLf_5jyj76q7qw'
this returns:
Reading link metadata...
Oooops, something went bad. EXIT CODE (3)
Which tells me that at least the code is running, but I don't know if I am doing it correctly.
This is better than my previous attempt $ megadown 'URL' (as the documentation suggested), which resulted in "command not found"
First, make sure you have installed the dependencies:
sudo apt-get install openssl curl pv jq
Then try running this command:
bash megadown.sh -o FILE_NAME "LINK"
It will download the file specified by the URL to a file called FILE_NAME.
Last login: Mon Jun 17 10:41:49 on ttys000
-bash: export: `2019.03': not a valid identifier
XXX:~ YYY$
(Note the XXXs and YYYs are just replacement)
Specifically, I am talking about the
-bash: export: `2019.03': not a valid identifier
I just installed Anaconda on Mac and then tried to update it and did in it incorrectly and now when I open the terminal, this appears every time. I know that 2019.03 is the current version of Anaconda and I have since fixed Anaconda so that my version is currently that version but I do not know what this "not a valid identifier" this is. Any help with how to address what it is, why it is there, and how I can remove it would be much appreciated.
EDIT: Thanks for assistance. I opened the bash profile and some of the comments was in the same line as the export path line and that was messing it up. Thank you!
If you open the terminal and see that there is some error coming from ~bash, it likely has something to do with the bash profile. You should open that up and check to make sure that nothing is out of place like having more than one thing on the same line since it can be sensitive to that.
You see the following due to the anaconda3 2019.03 installer trying to export a non valid identifier from your .bash_profile file. Note, this file is usually hidden due to the period in front of the file name.
The following is what was appearing in my terminal:
-bash: export: `2019.03': not a valid identifier
Do the following to fix this issue.
$ nano .bash_profile
Now you should be inside of the .bash_profile file using the nano editor.
# comment out or remove the following line from .bash_profile
# then save before you exit the file
#export PATH="MAMP_PHP:$PATH"# added by Anaconda3 2019.03 installer
Close your terminal and open it again, and the annoying "-bash: export: `2019.03': not a valid identifier" should be gone whenever you open a new terminal.
So, the last week or so I've been struggling trying to get my nginx server to run off of Docker/Laradock. The weird thing is that it worked when I was running it off C:/, but after being told by work that I had to encrypt my disk, I downloaded VeraCrypt and made an encrypted drive Y:/ and copied my vhosts folder into there.
After a lot of struggles trying to even get the laradock_nginx_1 to attach, I followed this guide, as I thought maybe Docker Toolbox didn't have access to the Y:/ drive. This seemed to work, but I still get a weird error when trying to get nginx up and running:
Y:\vhosts\laradock>docker-compose up nginx
WARNING: The PHP_FPM_INSTALL_TOKENIZER variable is not set. Defaulting to a blank string.
laradock_workspace_1 is up-to-date
Starting laradock_docker-in-docker_1 ... done
Starting laradock_php-fpm_1 ... done
Starting laradock_nginx_1 ... done
Attaching to laradock_nginx_1
nginx_1 | /opt/startup.sh: line 2: $'\r': command not found
nginx_1 | /opt/startup.sh: line 10: syntax error: unexpected end of file
laradock_nginx_1 exited with code 2
Read somewhere else that the \r was simply the line ending of Windows. I tried to cd into /opt/startup.sh, but it didn't seem to exist. I found out that there was another startup.sh inside laradock/nginx/, I ssh'ed into the Docker VM and saw that every line ended with ^M, which I suspect might've been \r. I removed those, but nothing really changed, still got the same problem.
While in ssh, I also did a hexdump of the startup bash file using hexdump startup.sh | grep 0d0a, but nothing came up. I'm at a loss for solutions, and not really sure what else I can try to do. Please note that Docker for Windows or BitLocker is out of the question since I only have Windows 10 Home.
What could I try to remedy this problem? Is this a known problem?
You can try to convert laradock\nginx\startup.sh file's windows style line endings to linux style line endings, i.e. with Notepad++ ( Edit > EOL Conversion > Unix (LF) ).
Then try to start nginx container with rebuild option:
docker-compose up --build nginx
I have Vim on Windows server 2012, and when I start it from the start menu everything works fine. However, when I start it from the command line it take 5 seconds and uses 700MB memory. Even when its not opening a file. There is something weird going on, and I was wondering if there are any ways to debug it/figure out what is causing this? Thanks, Eric.
EDIT:
Here is the result of vim --startuptime outputfile (abbreviated):
times in msec
clock self+sourced self: sourced script
clock elapsed: other lines
000.000 000.000: --- VIM STARTING ---
...
016.000 016.000: parsing arguments
016.000 000.000: expanding arguments
4794.000 4778.000: shell init
4794.000 000.000: Termcap init
...
4825.000 000.000: setting raw mode
8768.000 3943.000: start termcap
8768.000 000.000: clearing screen
8783.000 000.000: --- VIM STARTED ---
You could use Sysinternals' Process Explorer to check if any of the processes are starting child processes or if there is any difference in the environmental variables.
Also, Sysinternals' Procmon would allow you to check what registry entries, files, etc does any application use (filter by command name includes vim), but probably you will find the differences just with Process Explorer.
Sysinternals was a company that created some nice apps for Windows and Microsoft bought it some years ago. You can access the last version of any of their apps on http://live.sysinternals.com
Excerpt from Vim FAQ 2.5:
2.5. I have a "xyz" (some) problem with Vim. How do I determine it is a
problem with my setup or with Vim? / Have I found a bug in Vim?
First, you need to find out, whether the error is in the actual runtime
files or any plugin that is distributed with Vim or whether it is a
simple side effect of any configuration option from your .vimrc or
.gvimrc. So first, start vim like this:
vim -u NONE -U NONE -N -i NONE
this starts Vim in nocompatible mode (-N), without reading your viminfo
file (-i NONE), without reading any configuration file (-u NONE for not
reading .vimrc file and -U NONE for not reading a .gvimrc file) or even
plugin.
In this invocation, try to reproduce your problem. If the error
persists, the chance is good you've found a bug in Vim (see also
Question 2.6. faq-2.6)
If the error does not occur when starting Vim this way, then the problem
is either related to some plugin of yours or some setting in one of your
local setup files. You need to find out, what triggers the error, you
try starting Vim this way:
vim -u NONE -U NONE -N
If the error occurs, the problem is your .viminfo file. Simply delete
the viminfo file then. If the error does not occur, try:
vim -u ~/.vimrc --noplugin -N -i NONE
This will simply use your .vimrc as configuration file, but not load any
plugins. If the error occurs this time, the error is possibly caused by
some configuration option inside your .vimrc file. Depending on the
length of your vimrc file, it can be quite hard to trace the origin
within that file.
The best way is to add :finish command in the middle of your .vimrc.
Then restart again using the same command line. If the error still
occurs, the bug must be caused because of a setting in the first half of
your .vimrc. If it doesn't happen, the problematic setting must be in
the second half of your .vimrc. So move the :finish command to the
middle of that half, of which you know that triggers the error and move
your way along, until you find the problematic option.
It also mentions how to create a log file:
You can also use the -V command line argument to get more debug
information to analyze the problem:
$ vim -V2logfile
You can increase the value passed to the -V argument to get more debug
information. By also specifying a logfile name, this makes sure, the
debug messages don't appear on the screen and won't disturb you when
trying to reproduce the problem.