The commands I use to compile a Latex terminal is:

$latex <file>.tex
$dvips -Go -ta4 -Ppdf <file>.div
$ps2pdf <file>.ps

What I want to do is make an script that I will run like $./ltx <file>.tex and it will make all the commands listed above, changing the .tex extension to .div and .ps when necessary.

How do I that and what do I have to study to know how to do this kind of stuff in the future?

  • 6
    You may find How to properly 'make' a latex project? illuminating Aug 25, 2016 at 18:19
  • 2
    While there may still be some special cases where creating a DVI makes sense, one can typically use pdflatex in place of latex and get the PDF file directly.
    – John1024
    Aug 25, 2016 at 19:29

2 Answers 2


Save the following as ltx:


latex $1.tex
dvips -Go -ta4 -Ppdf $1.dvi
ps2pdf $1.ps

Make it executable chmod 755 ltx

Have a look at bash scripts how to make scripts.

Edit: Suggestion fro Kalvin Lee (comment below): to make the script available from everywhere, copy it to a directory on the path: very probably the most appropriate place being /usr/local/bin.

  • Two footnotes to the asker: make sure that you put this somewhere where your PATH can find it, and don't name your latex files with whitespace. Or quote your variables.
    – Kalvin Lee
    Aug 26, 2016 at 0:55
  • 1
    @Kalvin Note that the original poster explicitly mentions he wanted to execute the script as ./ltx ..., so he expects the script to be in the same directory as the .tex files. You're right about spaces in the file name. I've somewhat given up on using spaces in filenames, as problems continue to pop up in unexpected places.
    – jcoppens
    Aug 26, 2016 at 14:34
  • Ah, my bad. Thank you for the correction. And I'm the same - though certainly it may not look pretty in a listing, the batch advantages are many when you name unadventurously...
    – Kalvin Lee
    Aug 26, 2016 at 14:36
  • 1
    Note only batch files are problematic - passing (space containing) filenames as parameters to programs tends to be unpredictable (even when escaped or quoted). You don't know how each program processes those internally. A surprisingly high number of them fails.
    – jcoppens
    Aug 26, 2016 at 14:50
  • Some related good reading at unix.stackexchange.com/q/131766/117549
    – Jeff Schaller
    Aug 26, 2016 at 15:41

I'll enter another Answer just to give some additional perspective for future efforts.

Part of your Question says

run like $./ltx <file>.tex ...

which implies (via the ./ syntax) that the ltx script exists in your current directory. This is an artificial limitation, IMHO, as maybe next week you want to work on some different files in a different directory.

Creating a shell script is one obvious solution to the problem -- you have multiple commands that you chain together all the time, and you don't want to type them every time you want to generate a new postscript file. jcoppens showed how to do this; as one of the commenters pointed out, you can put this shell script somewhere more central (~/bin?) and update your $PATH to include that directory so that you can then type ltx file.tex anywhere there's a file.tex and it'll do what you want.

Another option is to create an alias. Aliases are limited, though, because the shell only expands them when they are the first word in your command, and don't have a way to refer back to the passed parameter multiple times (it just gets appended to your alias text).

Yet another option is to create a function. Functions can be defined in your shell's startup files and so would not need any modification to your $PATH and could be executed from any directory you find yourself in.

Here's a first draft of a function that does what you want:

function ltx() {
  latex "$1" && \
    dvips -Go -ta4 -Ppdf "${1%.tex}.div" && \
      ps2pdf "${1%.tex}.ps"

I've made two major modifications and one minor tweak to your initial commands:

  1. at the ends of the lines, I've added && symbols that tell the shell: "only execute the next command if this previous one has returned successfully." This saves extra errors if you've specified a file.tex that doesn't exist, or if the latex command fails for some reason. The last character in the line, \, tells the shell that the following line should be considered part of the current line -- a continuation. It's not strictly necessary in this case, since the shell recognizes && as requiring another command to follow it. I like to include it in scripts that I write to make it more obvious that the intention is for these two (or more) lines to go together. I've also indented the subsequent lines to make it even more clear.

  2. I've changed file.tex to $1 in the first call, and used bash's parameter expansion in the following calls, in order to refer to the file.tex that you pass to the function and then to remove the .tex extension to add back in the .div or .ps extensions.

  3. I've also quoted the variable expansions so that you can name your file file with spaces.tex if you'd like, and the shell will preserve the filename across all of the commands.

This first draft of the function will work, but I'll point out a couple extra steps that I would take:

function ltx() {
  [ -r "$1" ] || return 1
  [[ $1 =~ .tex$ ]] || return 2
  echo latex "$1" &&
    dvips -Go -ta4 -Ppdf "${1%.tex}.div" &&
      ps2pdf "${1%.tex}.ps"

The first new additional line checks to see if the parameter you passed in actually exists and is readable. If it's not, the function will return without calling any other commands, with a return code of 1. You could change this test to output something else (That file does not exist, please try something else), or keep it out entirely, knowing then that the latex command will give you an error about a missing input file.

The second additional line is bash-specific, and is checking to see that the parameter you passed in ends with the string .tex. I added this because the subsequent commands expect such a file, and the parameter expansion is attempting to remove such an extension, so if you call ltx somefile, the revised function will return an exit code of 2 and not call latex.

The last part of your question is:

what do I have to study to know how to do this kind of stuff in the future?

I think you've started down the right road: you have a real-world problem that you think could be made better with a shell script (or somehow). You've come to an environment at U&L that has like-minded people with knowledge of these things. This site also has thousands of similar questions and answers that solve various people's specific problems.

Study other answers to similar questions, such as the ones in , , and (as you tagged originally). Sort through the highest-rated ones, or the shortest ones, or the newest ones, and see if you can understand how they work. Copy interesting ones to a playground area on your system and experiment with them. Change them to see what happens!

Look at the shells you might have available on your system (such as , , ) and read through their man pages to see what features they offer. Experiment with those features until you understand them. While reading through the descriptions, think of other problems that you might be able to solve or improve upon.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .