I am running OS-X El-Capitan with MacPorts. System language of my Mac is Spanish. How can I tell gnupg to use English as language for any output such as error messages?
I have installed gpg 1.4.19 via macports and gpg 2.0.28 via GPGTools. Both gpg -h and gpg2 -h produce Spanish output, while other unix commands such as git --help or man -h produce English output.
In this post a similar problem is discussed, but I could not apply the recommendations given there to my OS:
http://www.gossamer-threads.com/lists/gnupg/users/52908
Like lots of other internationalized tools, GnuPG takes the LANG environment variable into account. Either export the variable for the whole session, where it will be valid for all executed applications from this terminal (you could also add this to your dotfiles):
export LANG=en
gpg --version
or prefix LANG=en for individual calls of gpg if you only want to run it in English language a single time:
LANG=en gpg --version
Related
I'm using Vim on a Mac, installed via homebrew, version 8.0.
Vim --version shows +clipboard, and -xterm_clipboard.
I've tried
set clipboard=unnamed
in .vimrc
But I cannot get yanks to go on to the system clipboard. What do I do?
It should "just work" on MacVim. One of the reasons I'm using it is for its OSX integration, including clipboard.
brew install macvim
mvim defaults to graphical mode. To run it in terminal mode:
mvim -v
In the past, I had an alias for vim -> mvim -v which handles most cases. These days I use the following script in ~/bin/vim, which is in my $PATH:
#!/bin/bash
mvim -v "$#"
seems like something is overriding your clipboard setting after loading your vimrc.
try :verbose set clipboard?. It should tell you when and where this variable was last set.
This guide gives you a bunch of hints on what to do to figure out what's going on and fix the problem
I want to make my bash script deal with long parameters. I found getopt, but it isn't supported in OS X. Can anyone tell me why getopt was implemented by BSD, but not GNU?
I tried building getopt in GNU C lib, but it failed for my poor skills with Linux.
Did anyone do this work?
There is a brew bottle for getopt.
Just run brew install gnu-getopt.
You can either specify the path for it like
/usr/local/Cellar/gnu-getopt/1.1.6/bin/getopt
Or use brew link --force gnu-getopt so it will be linked in /usr/local/bin/
Just be aware that forcing linking might be corrupting your system (as it replaces the system getopt by the gnu one).
See maybe later answer suggesting to define FLAGS_GETOPT_CMD (though few comments state issues with it).
I recommend using Homebrew to install gnu-getopt and then adding $FLAGS_GETOPT_CMD to your ~/.bash_profile file to specify the cmd path for getopt, pointing at the homebrew location, like so:
brew install gnu-getopt
Then follow directions from brew to add to your local path:
sudo echo 'export PATH="/usr/local/opt/gnu-getopt/bin:$PATH"' >> ~/.bash_profile
Then you can add FLAGS_GETOPT_CMD:
sudo echo 'export FLAGS_GETOPT_CMD="$(brew --prefix gnu-getopt)/bin/getopt"' >> ~/.bash_profile
Open a new terminal, or run . ~/.bash_profile in existing terminal to load changes
Run echo $FLAGS_GETOPT_CMD to confirm it was actually set in your console
It's generally a better idea to use getopts instead, and stick with short options. You can see getopts in action in this StackOverflow Q&A. Short options are more standard throughout OSX command line tools, and consistency is a good thing.
Also, getopts is built in to bash, so it's definitely available in OSX, as well as every other platform that can run bash.
Note that there is a getopt is also available in OSX. From Terminal, type man getopt to see its documentation. It doesn't support long options. This is a good reason not to use long options when you're writing tools to run on OSX.
If you want to do this anyway, you can install getopt from macports. Alternately, if you want better portability, you can roll your own long argument handling.
Post some code, and we'll help debug it.
I am using Ubuntu 10.04. i have created a shell script. After writing the script, the code can be edited when right clicking the file and selecting Gedit. I want to know how to make the script unreadable in Gedit.
GEdit is just another tool that can be used to edit a file, much like "vi" or "nano" is. Only difference is, I believe it is graphical. Nevertheless, it appears that what the original poster is attempting to do here is to simply make it impossible for others to view certain scripts. If that's true, there are solutions that may be worth investigating.
SHC:
SHC is a great tool to use for this purpose. and based on the last post in this thread, it appears the OP has already tried it but, it didn't work on certain systems. If that's the case, heres's the reason why. The way SHC works is actually pretty straight-forward. When using it to obfuscate a script, you have to re-compile the script for whichever OS you intend to run it on. What that means is, you cannot run the SHC compiler on a ubuntu box and expect the produced script to work on a Red Hat/CentOS box. It appears the latest version of SHC can be accessed here.
EnScryption:
If your main goal is to discourage others from attempting to read your code, you can just paste your script to a site like this one. This site will automatically generate an obfuscated version of your script that should be able to run without issues on most common Unix systems.
If you do not wish to paste your code to the above site or use SHC for whatever reason, then, there's yet another solution. Use openssl!
OpenSSL:
If your scripts are really that sensitive, then Openssl(or a similar tool) is probably the best option for you. Why? Because the openssl tool in particular is present on most Unix systems...i.e. Ubuntu, CentOS, Red Hat, Macs, AIX. It comes as part of the default installation. If you decide to go this route, note, you will need to write your script in such a way that before it runs, the user has to provide a password.
Encrypting your script with OpenSSL:
cat yourscript.sh | openssl aes-128-cbc -a -salt -k (specify-a-password-here) > yourscript.enc.sh
(OR)
openssl aes-128-cbc -a -salt -in yourscript.sh -k (specify-a-password-here) > yourscript.enc.sh
(OR)
openssl aes-128-cbc -a -salt -in yourscript.sh -out yourscript.enc.sh -k (specify-a-password-here)
Decrypting your script with OpenSSL:
cat yourscript.enc.sh | openssl aes-128-cbc -a -d -salt -k (specify-a-password-here) > yourscript.dec.sh
(OR)
openssl aes-128-cbc -a -d -salt -in yourscript.sh -k (specify-a-password-here) > yourscript.dec.sh
(OR)
openssl aes-128-cbc -a -d -salt -in yourscript.sh -out yourscript.enc.sh -k (specify-a-password-here)
A quick thing to note about the openssl encryption mechanism 'aes-128-cbc':
There are probably more secure mechanisms out there. But there is a good chance some of the systems you wish to run your encrypted scripts on wont have those mechanisms, thereby making it impossible to run your script. So keep that in mind if you decide to change it.
Obfuscation (which is what most people mean when they say they want a "binary" shell script) is a Bad Idea(TM) - Been there, done that. It doesn't provide any security against a determined programmer (they'd just trace the script to figure out what it's doing), and it makes it really, really hard to debug (which, possibly unless you're GreyCat, you will need to do. A lot.).
You are probably looking for something like shc.
From the man page:
shc creates a stripped binary executable version of the
script specified with -f on the command line.
http://freecode.com/projects/shc
Disclaimer: I have not tested shc nor do I know how well/if it works
What you want to do is not readily possible. Scripts are interpreted, not compiled, that's why you see text in there.
For an script to be executed, the effective user must have read access to it. An alternative to giving execution permission or using shc (as KillerX has nicely proposed), without letting the user look at the contests of the script, would be to use sudo. You would edit the sudoers file like this (remember to use visudo to edit this file!):
username ALL=(ALL) /path/to/your_script.sh
Now the script would be executable by "username" but he wouldn't be able to read its contents. Of course, you need to remove all permissions to "username" from this file...
I am trying to run a Python script that involves PyQt Webkit on a headless server using xvfb. The following command works when I run it from the command line, but not from a bash script:
# !/bin/bash
xvfb-run -a -e /path/to/error.log python script.py
The error log shows the following in both instances:
[dix] Could not init font path element /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, removing from list!
which I read could be ignored. The script runs fine when the bash script is just:
# !/bin/bash
python script.py
aka without Xvfb. Is there something about the bash environment that would prevent the script from running with xvfb? I'm stumped!
I wouldn't ignore that error. It leads to incorrectly rendered fonts if you're attempting to perform screen captures. To get rid of the error (and hopefully your larger issue), you'll need to install the TrueType fonts as follows (Ubuntu syntax here):
sudo apt-get -y install x-ttcidfont-conf cabextract ttf-mscorefonts-installer
(you'll have to enable the multiverse repo to get ttf-mscorefonts-installer)
Accept the EULA terms for ttf-mscorefonts-installer.
Then:
sudo dpkg-reconfigure x-ttcidfont-conf
(choose the freetype fonts).
You should then have cleared the error which will hopefully both fix your issue and cause fonts to render correctly.
I am having issues pulling from a YAML config file:
Fatal error: while parsing a block mapping; expected <block end>, but found block entry
While there are plenty of online YAML validators, which I have tried and have helped, I'd like to validate my YAML files from the command line and integrate this into my continuous integration pipeline.
With basic Ruby installation this should work:
ruby -ryaml -e "p YAML.load(STDIN.read)" < data.yaml
Python version (thx #Murphy):
pip install pyyaml
python -c 'import yaml, sys; print(yaml.safe_load(sys.stdin))' < data.yaml
You could use yamllint. It's available in Homebrew, etc. It can be used for syntax validation as well as for linting.
Given that you have a perl install on the server you are working on, and it has some of the basic YAML tools, you can use...
perl -MYAML -e 'use YAML;YAML::LoadFile("./file.yaml")'
It should be noted that this will be strict in it's interpretation of the file, but useful.
To correct your .yaml files I recommend the tool yamllint. It can be launched easily from the local console.
The package yamllint is available for all major operating systems.
It's installable from the system's package sources. (e.g. sudo apt-get install yamllint).
See documentation for quick start and installation.
My preferd way is
yamllint -d "{extends: default, rules: {quoted-strings: enable}}" .
Since I really want to catch quote errors,
e.g. validate: bash -c ' ' \""
This is valid yaml, since yaml will just quote the string and turn it into:
validate: "bash -c ' ' \\\"\""
Whilst there was just clearly a quote missing at the beginning of the validate comand.
So a normal yaml checker will not detect this, yamllint wil not even detect this in it's default configuration, so turn on quoted-strings checker.
If you got no interpreter installed in your environment but still got a curl, then you could use an online linter project like Lint-Trilogy:
curl -X POST --data "data=$(cat myfile.yml)" https://www.lint-trilogy.com/lint/yaml/json
It delivers the validation result incl. error descriptions (if any) as json or csv or, where sufficient, as plain text true or false.
It's available as docker file, too. So if you often need a REST based linter, perhaps in a CI/CD pipeline, it may be handy to host an own instance on your site.
Or alternately installed (free) Eclipse IDE and then YEdit yaml editor and see your yaml with syntax highlighting, error flags, and outline views. One time setup cost works pretty well for me.