I'm a novice when it comes to these things, so please, be gentle.
I'm trying to us Ghostscript, but I cant even launch a command. I'm trying to run this little bit of code that someone posted.
gswin32c.exe ^
-o c:/path/to/output.pdf ^
-sDEVICE=pdfwrite ^
-dPDFSettings=/Screen ^
[...more desired parameters (optional)...] ^
/path/to/first.ps ^
/path/to/second.ps ^
/path/to/third.pdf
I've made sure my file paths are correct, but I can't even figure out how to drop down a command line. I have tried launching Ghostscript and the code from command prompt, but Ghostscript gives me an error saying " undefined in -o".
Any help would be greatly appreciated.
First thing you should do is reduce the complexity of your command line. From the command shell try:
gswin32c
Do you get a bunch of GS copyright messages and a 'GS>' prompt ? If you do then type 'quit' then press return and you should be back to the command shell. This means Ghostscript is installed, in your path and working. (Since you got an error message I suspect this will be fine)
After that, try something like:
gswin32c -o out.pdf -sDEVICE=pdfwrite
When you get the 'GS' prompt type 'showpage' and press return. At the next prompt type 'quit' and return.
That should create a PDF file in the current directory called out.pdf with a single blank page.
After that you can build up your command line bit by bit. Note that there is no switch called PDFSettings, its actually called PDFSETTINGS, the command line switches are case-sensitive. I would also firmly recommend that you don't use it. That switch sets a load of parameters (documented in ps2pdf.htm) many of which are probably irrelevant to you and some of which have results you don't want. Work out what you do want and set the parameters individually.
Related
I have a function (written below; source: TeX SX) that uses pipes in the shell which I'd like to use in vim command mode. It works as intended from the shell but returns an E34: No previous command error if entered in vim command mode. Full credit goes to jirislav in this post on TeX SX.
: | pdflatex -halt-on-error src.tex | grep '^!.*' -A200 --color=always
I'd very much like to have this shell functionality from the vim command line if anyone can help with that.
I tried the following from within vim command mode:
:! : | pdflatex -halt-on-error src.tex | grep '^!.*' -A200 --color=always
returns the E34 error. No pipes hides all compilation; however, it also doesn't output errors. Deleting 1 of 2 of the pipes also returns E34 errors for me.
I tried further troubleshooting to no success and here are some results of that. The help for :! says
a pipe '|' in {cmd} is passed to the shell, you cannot use it to append a vim command. See :bar
and :bar says (something that's referred to as escaping it out I think)
'|' can be used to separate commands, so you can give multiple commands in one line. If you want to use '|' in an argument, precede it with '\'.
I tried doing what :bar suggests, i.e.
:! : \| pdflatex -halt-on-error src.tex \| grep '^!.*' -A200 --color=always
The result is it hides everything, including compilation errors that I want to see. So I've come to the conclusion that I have no clue how to properly use shell pipes in vim command mode.
If you aren't a LaTeX user, all that the function is meant to do is the following. pdflatex compiles what's going on in vim into a pdf file. Enacting :! pdflatex % from vim's command mode outputs a whole slew of processing text and interrupts workflow; the grep in the function yanks out compilation errors, if they exist. The function, then, is meant to hide all output from pdflatex unless a compilation error occurs, in which case it outputs only the error and outputs it in red.
If anyone cared to explain the E34 error and why it doesn't work that would be appreciated, also.
Edit 1: This is now solved thanks to filbranden. Below there are a couple pictures attached of a minimal example should anyone come across this later.
vim file before input, output
Edit 2: Should you want to stick this in your .vimrc file, you'll need to escape out the pipe before grep, else the vimrc file defaults to thinking that pipe is a separator.
E34: No previous command
So the answer to your question was hiding in plain sight under :help E34, which redirects to the :! command.
(Vim pro-tip: whenever you get an error from Vim, ask for :help on the error code to get more context about it.)
The section on :! includes this passage:
Any ! in {cmd} is replaced with the previous external command. But not when there is a backslash before the '!', then that backslash is removed.
You did have a ! in your command, as part of the grep regular expression, ^!.*, so that was triggering the "history" behavior, trying to replace with the previously executed command. But since no command had executed at that point, the command failed with an error.
You can solve it by escaping the ! with a backslash, which Vim will remove before passing the command to the shell:
:! pdflatex -halt-on-error src.tex | grep '^\!.*' -A200 --color=always
But note that there are better ways to approach this problem! Let me cover some of them.
Using systemlist()
One great way to run external commands in Vim is to use the systemlist() function, which runs the command on a shell, captures its output, splits it into lines and returns a List with the resulting output lines.
So you could start with:
let latex_output = systemlist('pdflatex -halt-on-error src.tex')
And then use Vimscript commands to check for lines starting with ! to report to the user.
Note that, unlike with :!, the output of systemlist() is never displayed to the user (which means you don't switch back to seeing a terminal, possibly a blank one, and after the execution you don't have a "Hit enter prompt.) Which is great!
But that means you need to present that information to the user, when there are errors. A great way to do that is to use the quickfix window!
You can use the setqflist() function to set the contents of the quickfix window.
(For best results, you should set 'errorformat' appropriately, more on that later.)
Using vim-dispatch
If you don't like the part of running an external command (either through :! or systemlist()) that has it block Vim until the command execution is completed, then consider installing the vim-dispatch plug-in.
It can execute a command for you in background or in a separate terminal, so you're not blocked from editing. It also integrates with the :make command and the quickfix window.
Compiler configuration in vim-latex
Finally, the vim-latex plug-in (also known as latex-suite) has configurations to help you run pdflatex and report errors.
It includes a Vim :compiler configuration that will run pdflatex for you as a :make program. It also will set 'errorformat' to recognize the ! LaTeX Error string and recognize the line number of the errors, so you can jump to them directly from the quickfix list.
Note that vim-latex also has many other features to help you write LaTeX documents in Vim (besides managing the output generation through the compiler support.) You might want to check these other features as well.
(Since the plug-in has quite many features, I recommend reading the whole documentation to get you started on it.)
Also note that this plug-in is compatible with vim-dispatch (since vim-latex provides a compiler interface and vim-dispatch consumes it), so you can use both together if you like them both!
I'm trying to pass some data to octave by writing to the windows command line from python in one single line, but I am getting an error.
I found some sample code at https://octave.org/doc/v4.4.0/Printing-and-Saving-Plots.html and I made a one line variation of it to suit my needs:
f=figure('Visible','off');plot([1,2,3,4]);pause(1);print(f,"myplot.pdf","-dpdflatexstandalone");
when I run this one line in octave itself, it works flawlessly, and I can find a file named myplot-inc.pdf in the octave folder (it will be in a different location in the future once i actually get the code to work). However, when I run it from command line using
octave --silent --persist --eval f=figure('Visible','off');plot([1,2,3,4]);pause(1);print(f,"myplot.pdf","-dpdflatexstandalone");
it gives this error:
error: 'test_plot' undefined near line 1 column 60
I would like to eventually run it without the --persist option, possibly even using -W to prevent octave from opening, if at all possible. For now, how can I make this code work from the command line in the same way it works in octave?
I figured out why this happened fairly quickly. since I'm running from command line, I have to use single quotes around 'myplot.pdf' and '-dpdflatexstandalone' instead of double quotes.
I have created a Windows 7 shortcut in an attempt to give someone who is not comfortable with R the ability to run a simple program. I have tried to follow the advice of other postings, but must be missing something. This is what I have in my shortcut right now.
Target: "C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla -e "C:\Users\Moo\Desktop\CharCalendar.r"
Start in: "C:\Program Files\R\R-3.0.2\bin\x64"
I get error messages (that flash up very briefly on a black DOS window) that say things like Error unexpected input in "C:\"
I have tried with and without quotes in the target, I have tried using source() in the target (also with and without quotes).
The script runs without error when I submit it in the R console.
You probably want
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" --vanilla C:\Users\Moo\Desktop\CharCalendar.r
as your target. No -e; that specifies an expression to run, not a script file.
I must admit, I hardly ever made my own shortcut in Windows. However, you coul seemly write a bat-file which runs the R-script and PAUSES, so you can read the output:
#echo off
"C:\Program Files\R\R-3.0.2\bin\x64\Rscript.exe" "C:\Users\Moo\Desktop\CharCalendar.r"
PAUSE
You may also want to add additional options and arguments after Rscript.exe. If you want to pass it to Rgui.exe, it will be a trickier. Read the following stackoverflow-topic for hints:
Passing script as parameter to RGui
Replace Rscript.exe -e with Rterm.exe -f, which indicates that you are passing a file as argument, -e is for passing expressions e.g. Rscript.exe -e "a<-1:10; mean(a);" Rterm provides a few more options for control compared to Rscript, see Rterm.exe --help.
I'm trying to write a script that contains this
screen -S demo -d -m which should start a new screen session named demo and detach it.
Putting screen -S demo -d -m in the command line works.
If I put it in a file named boot.sh, and run it ./boot.sh I get
Error: Unknown option m
Why does this work in the command line but not as a shell script?
This file was transferred from windows and had ctrl-M characters.
Running "screen" on my Linux machine, a bad option (Screen version 4.00.03jw4 (FAU) 2-May-06) gives the error,
Error: Unknown option -z"
while your description includes no dash before the offending option. I'd check that the characters in your script file are what you expect them to be. There are many characters that look like a dash but which are not.
cat -v boot.sh
may show something interesting as it'll show codes for non-ascii characters.
This may seem a little like the "make sure your printer is plugged in" kind of help, but anyway:
have you tried to check if the screen you're invoking from the script is the same as the one invoked from the command line ?
I'm thinking you may change the PATH variable inside your script somewhere and perhaps screen from the script would be something else (a different version, perhaps ?).
I am trying to use doxygen to generate documentation for some matlab classes I have written. I am using the doxygen-matlab package, which includes a perl script to kludge matlab .m files into c++ style commented files, so that doxygen can read them.
In my doxyfile, I have set (according to the instructions)
FILTER_PATTERNS = *m=C:/doxygenMatlab/m2cpp.pl
However, when the code runs, rather than running the script on the input files, it appears to just open the script using whatever the default windows setting for .pl is.
IE, if I associate .pl with notepad, the script is opened by notepad once for each input file doxygen is trying to parse. If I associate .pl with perl.exe, the script runs and throws the no argument error
Argument must contain filename -1 at C:\doxygenMatlab\m2cpp.pl line 4.
The doxygen documentation says
Doxygen will invoke the filter program by executing (via popen()) the command <filter> <input-file>
So I am wondering if there is some problem with popen() and windows that I could fix.
Could you try the workarounds I posted on the Matlab File Exchange regarding the doxygen package ?
Set the following variables in the Doxyfile :
INPUT_FILTER=perl m2cpp.pl
FILE_PATTERNS=*.m
If it doesn't work you should try to install ActivePerl : with this version of perl, everything is working fine.
I tried to reproduce the error using the Windows command prompt ("cmd") and noticed the following:
If you call "perl m2cpp.pl" you get error -1 because you did not specify a m-file to be translated into a cpp-file.
If you call "perl m2cpp.pl mfile" and the path of mfile contains spaces, you get error 1.
After I moved the mfile into a location which does not contain spaces, I got the desired output.
Now back to Doxygen. I tried what you suggested, Fabrice, without any luck. I read the doxygen help and found out that the INPUT_FILTER variable is only read and used if FILTER_PATTERNS is empty.
Therefore, I now use INPUT_FILTER = "C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl" and an empty FILTER_PATTERNS variable. With this configuration, you can even leave the PERL_PATH variable empty. Moreover, there seems to be no issues with file names that contain spaces.
Unfortunately, all files are parsed with the above configuration, not only m-files. However, setting FILTER_PATTERNS to something like *.m=C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl does not work because doxygen automatically adds the name of the filtered mfile and interprets the command as perl "m2cpp.pl mfile". Of course, the file "m2cpp.pl mfile" does not exist, because these are two files.
Maybe you can find a solution to this problem. In the meantime, I suggest the workaround above and that you keep your C-files away from the folder that contains the m-files.
write a simple batch file, e.g. mfilter.bat, which takes one argument from command line:
C:\Programme\MATLAB\R2009a\sys\perl\win32\bin\perl U:\doxygen_matlab\m2cpp.pl %1
Change setting in Doxyfile:
FILTER_PATTERNS = *.m=mfile.bat
This did it for me (on a Windows platform)
I think I solved this problem : it came from a bad association between .pl and the program to execute (maybe due to a bad installation of the perl shipped whith Matlab ?).
To correct this, you should change the association for the .pl files : in a Windows command prompt ("cmd"), just type de 2 following lines :
assoc .pl=PerlScript
ftype PerlScript=C:\Program Files\MATLAB\R20xx\sys\perl\win32\bin\perl.exe %1 %*
(the old installation forgot the %* at the end, the arguments were not passed to the m2cpp.pl script).
And then everything should be fine with the FILTER_PATTERNS set the usual way, for example FILTER_PATTERN=*m=C:\DoxygenMatlbab\m2cpp.pl
Could you tell me if this fixed your problem ?
According to the Doxygen forums, there is a difference in behavior between using INPUT_FILTER and FILTER_PATTERNS.
I found that if I do some extra (escaped) quoting, I can get FILTER_PATTERNS to work. For example, instead of:
FILTER_PATTERNS = "*.m=sed -e 's|%%|//!|'"
Try:
FILTER_PATTERNS = "*.m=\"sed -e 's|%%|//!|'\""
(All of my experimentation was done with doxygen version 1.8.6)