Is it at all possible to set default options for pandoc? For example, I always want to use xelatex to generate PDFs, and as far as I can tell, my options for doing so are to pass --latex-engine=xelatex to every invocation of pandoc, or to write a wrapper script that just calls pandoc with that option.
Both of these seem suboptimal to me, and nearly every other command-line program has ways to get around this. Sometimes it's done with an environment variable in the shell (something like setting PANDOC_OPTS="--latex-engine=xelatex"), and other times it's a configuration file (ala ~/.gitconfig or the like). I know pandoc has a data directory at ~/.pandoc, but from my reading of the documentation there is no way to do this.
Since pandoc 2.8, one can provide default options via the --defaults command line parameter:
-d FILE, --defaults=FILE
Specify a set of default option settings. FILE is a YAML
file whose fields correspond to command-line option
settings. All options for document conversion, including input
and output files, can be set using a defaults file. The file will
be searched for first in the working directory, and then in
the defaults subdirectory of the user data directory
(see --data-dir). The .yaml extension may be omitted.
See the section Default files for more information on the
file format. Settings from the defaults file may be
overridden or extended by subsequent options on the command
line.
Related
While following a training, I ran vim /etc/ansbile/ansible.cfg on my Mac.
In the training video, this command loads a default ansible configuration file while on my Mac it came back with a blank page.
How can I get a default config file to start editing it?
There is no default ansible configuration file by default. In other words, ansible does not create any system wide configuration file at install and will use default values for all parameters if run without any existing configuration file (system wide, user home, project level...)
Since you are trying to edit a file which does not exist, vim starts with an empty buffer to create a new file.
You can easily create an ansible.cfg file containing commented out default values of all known parameters and store it wherever you like with the following command:
ansible-config init --disabled -f ini > /tmp/ansible.cfg
I am writing an Ansible role that installs and updates some specific enterprise software. I would like to compare the installed version (if it is installed) to the one I am trying to install, for various reasons, but mainly to be able to verify that installation is necessary and allowed before actually executing the installer. Both installer package and installation contain an INI-file which contains component versions as options (component_name=version).
What is the proper way in Ansible to read some option(s) from some INI-file on remote node? As far as I understand:
ini_file -module is meant for modifying target file, which is not what I want to do.
ini lookup is meant for files on controller, not on remote nodes.
I can see two possibilities here:
Use fetch -module to get file from remote node to controller machine, then use ini lookup.
Use command or shell -module, parse INI file using grep/sed/awk and register output.
The first option seems unnecessarily clumsy (although I do realize I may think about it in the wrong way). Second one seems a bit clumsy from another point of view (yet another INI-file parsing method), but I may be wrong here too. Right now I am leaning on the latter, but I can't help thinking that there must be an easier and more elegant way.
Seems like a use case for facts.d.
Write a shell or Python script that inspects those ini files and dumps required fields as JSON object to stdout.
Place this script into /etc/ansible/facts.d/custom_soft.fact and make it executable.
Then you can use these facts as follows:
- shell: install_custom_soft.sh
when: ansible_local.custom_soft.component_ver | int > 4
If your ini files are very simple, you may do the job even without script, just make a link like this:
ln -s /etc/custom_soft/config.ini /etc/ansible/facts.d/custom_soft.fact
and all config.ini keys will be available to Ansible via ansible_local.custom_soft variable.
P.S. Despite the name "local facts" this should be done on remote machine.
I'm trying to install the Google SDK
I type:
export PYTHONPATH=$PYTHONPATH:/Users/morganallen/Dropbox/google_appengine
then:
echo $PATH
And I see:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/morganallen/Dropbox/google_appengine
But when I quit terminal and re-open it and type echo $PATH I only see:
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Why isn't it saving?
I've seen other answers mentioning a .bashrc file, but I can't find mine? Not sure what to do.
If you type that into the command line, it only applies for the current session (until you close the bash window). Instead, save that line of code into your .bash_profile and it should work for every single session.
A file whose name begins with a period (.) is a hidden file. Depending on the file manager/browser which you may be using, hidden files may not be shown by default. You will need to enable viewing hidden files in the preferences/options as the case may be.
If you are using a command line to list the contents, you can use ls -a instead of plain ls.
And of course, if you need to modify the hidden file using a text editor at the command line itself, (say, using vim/nano etc.) then you can always supply the full name of the file as an argument (including the period).
Say I've got a .vsprops file that is used in a solution. In that file, various variables are defined such as int_dir for intermediate build results and log_dir for the log results.
Usually, these variables get set to default values (relative to the solution).
For me, I'd like to set these two variables to my ramdisk (R:), i.e. no longer
$(SolutionDir)\intermediate
but
R:\myproject\intermediate
If I change the .vsprops file directly, the source control (Git) will mark it as modified.
Is there a way in VSPROPS so that I could check maybe an environment variable and if this variable is not set, the default is used?
If this is not possible, I'd also be interested in a solution for Git to overcome this (but not --assume-unchanged and not .gitignore because maybe other changes in that file could be relevant).
A pure Git solution could use a gitattribute filter driver:
It would involve a smudge script, executed on git checkout, which would:
detect if you want to change $(SolutionDir) (for instance, test for an environment variable with the updated path in it)
detect the right file (xxx.vsprops.tpl) content (the script doesn't know the file names or path it operates on)
generate the actual .vsprops from a .vsprops.tpl (template file) which is the one being versioned (the .vsprops is no longer versioned)
You can add a clean script which would preserve (on git commit) all the modification done in the .vsprops file back to the .vsprops.tpl, except for the $(SolutionDir) line.
I created a simple program that takes the path of a directory as an input, creates an archive of that directory (converting it into a single file), adds a shebang to that file (so that the contents of the file can be easily extracted), and writes the file to the base directory of the specified path.
The problem is that the file does not extract itself when I double click on it. Instead the operating system (I'm using Ubuntu 11.10) tries to open it with gedit. This obviously shows the shebang, random gibberish, and the contents of the archived files.
I made the file executable, first by using chmod +x; and when it still didn't work I tried chmod 777. However it still refuses to execute the file with the shebang when I double click on it. Perhaps this is because it's not a pure text file.
Interestingly when I try to execute the file directly from command line it reads the shebang and extracts the contents of the archive properly. So there's nothing wrong with my file format. I don't know much about what operating systems do when you double click on a file but I would sure like to understand.
It surely makes no sense to add a shebang to a file if you still need to manually execute it from the command line. One advantage could be that you don't need to specify the program to open it with but I believe that's hardly an advantage. Any help will be greatly appreciated.
Update 1:
The program that creates the archive is called opm. It can be installed via the node package manager using the following command:
npm install opm
After that you simply use opm to pack and unpack directories for you. For example if I have a directory called test in my home directory then I can open a terminal and execute the following command to pack it:
opm test
This will create an archive of the directory called test.pack in the home directory. The .pack file has the shebang #!/usr/bin/opm. Opening a file with the extension .pack with opm tells it that it's an archive and opm unpacks it in the same directory.
Note: Change the name of the test.pack file if you do not want it to overwrite your existing test directory.
I added the shebang to the .pack file so that it would extract itself when I opened it. However that doesn't seem to work. Nevertheless if I run one of the following command then it works:
./test.pack
You may check my source code and make any modifications to the program as you may wish to.
Update 2:
Alright I created the following .desktop file for opm and stored it in the $HOME/.local/share/applications/ directory:
[Desktop Entry]
Type=Application
Version=1.0
Encoding=UTF-8
Name=OPM
GenericName=Object Packer and Minifier
NoDisplay=true
Comment=JavaScript Package Manager
TryExec=opm
Exec=opm %f
Terminal=false
MimeType=application/opm
Now I was able to associate .pack files with opm by right clicking on a .pack file, going to the Properties window, the Open With tab, and setting opm.desktop as the default application. Now I am able to unpack a .pack file by simply opening it.
However I would like to know how to associate .pack files with the mime type application/opm. Currently the .pack files are associated with application/x-java-pack200. How do I do so? Is it better if I use a different extension (e.g. .opm)? By associating the packed archives with the mime type application/opm will the OS open them with opm by default without having to explicitly set a default application from Properties > Open With?
If there's already a MIME-type associated with .pack then you'll want to use a different extension (.opm) to associate with your MIME-type (application/opm). The way you automatically associate a program that opens files of a specific MIME-type is with xdg-mime .
Alternatively,
Edit ~/.local/share/applications/mimeapps.list and put your MIME/application combo under [Default Applications] like so:
[Default Applications]
application/opm=opm.desktop;
Place your opm.desktop file in ~/.local/share/applications/ folder. (You've already done this)