Delete the input file after GhostScript finishes converting to PDF - ghostscript

Can someone show me how to use the PostScript deletefile operator to delete the input file after GhostScript finishes converting the input file to a PDF file.

This appears to work for me, first creating the PDF file, then setting the permissions on the input file, and finally deleting the input file.
"C:/Program Files/gs/gs9.55.0/bin/gswin64c.exe" -q -sDEVICE#pdfwrite
-o "C:/Temp/Temp_0001.pdf"
-f "C:/Temp/Temp_0001.ps"
--permit-file-all=C:/Temp/Temp_0001.ps
-c (C:/Temp/Temp_0001.ps) deletefile
NOTE: Since I had to switch to Unix-style path separators (even though I am running this on Windows) for the permit-file-all and the deletefile, I decided to use the same convention for both the output and input files as well. Windows seems to be OK with that, and the convention was uniformly used for all paths/files.

Related

Loop Over Files as Input for Program, Rename and Write Output to Different Directory

I have a problem with writing the output of a program to a different directory when I loop different files as variables as inputs. I run this in the command line. The problem is that I do not know how to "tell" the program to put the output with a changed filename into another directory than the input directory.
Here is the command, although it is a bioinformatic tool which requires specific input file formats. I am sorry that I could not give a better example. Nonetheless, the program is called computeMatrix in a software-tool box called deeptools2.
command:
for f in ~/my/path/*spc_files*; do computeMatrix reference-point--referencePoint center --regionsFileName /target/region.bed --binSize 500 --scoreFileName "$f" **--outFileName "$f.matrix"** ; done \
So far, I tried to use the command basename to just get the filename and then change the directory before that. However I could not figure out:
if this is combinable
what is the correct order of the commands (e.g.:
outputFile='basename"$f"', "~/new/targetDir/'basename$f'")
Probably there are other options to solve the problem which I could not think of/ find.

How to stop new line conversion when zipping a Windows text file on a Unix machine

I want to zip a windows .cmd file on an OSX server, using the zip command line tool.
templateName="Windows_Project_Template"
zip -r -T -y -9 "${templateName}.zip" $templateName
When the file is unzipped on a windows machine all the new line carriage returns are converted and so the text file comes out without any new line formatting on a windows machine. How can I work around this?
Thanks
While not a perfect solution (I can't find an option to handle everything as binary), you can force the \r\n with the --to-crlf option:
-l
--to-crlf
Translate the Unix end-of-line character LF into the MSDOS convention CR LF. This option should not be used on binary files. This
option can be used on Unix if the zip file is intended for PKUNZIP under MSDOS. If the input files already contain CR LF, this
option adds an extra CR. This is to ensure that unzip -a on Unix will get back an exact copy of the original file, to undo the
effect of zip -l. See -ll for how binary files are handled.
Be careful, if the file already contains \r\n you will get \r\r\n.

read directory file

we all know that in linux directory is a special file containing the file name and the inode number of constituent files. I want to read the contents of this directory file using standard command line utility.
cat . gives an error that I cannot open a directory.
However, apparently vim can understand the content of this file using readdir probably. It displays the contents of the directory file in a formatted manner. I want the raw contents of the file. How is this possible ??
As far as I can tell, it cannot be done. I was pretty sure dd would do it, and then I found the following
‘directory’
Fail unless the file is a directory. Most operating systems do not allow I/O to a directory, so this flag has limited utility.
http://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html
So I think you have your answer there. dd supports it, as do probably a number of other utilities, but that doesn't mean linux allows it.
I think stat might be the command you're looking for.

Concatenate files on Windows, and reverse operation

I'm currently trying to find a way to concatenate several files, typically all files from within a directory (recursive included) into a single stream, for further processing.
TAR looks like an obvious candidate, except that it is not at all standard in Windows, and unfortunately, all versions i could find (mostly variations of GNU TAR) are much too big (several hundreds of KB once included DLL dependencies). I need something much smaller.
Apparently, the standard COPY command could do the trick. For example the following command works:
COPY /B sourcefile1+sourcefile2 destinationfile
However, there are still 2 problems : I don't know how to write the result to stdout (for pipe), and even more importantly how to achieve the reverse operation ?
I need a small utility to do this concatenation job, either in C source code, a standard windows command, or as a distributable binary. It doesn't need to respect the TAR format (although it is not a bad thing if it does). And obviously the concatenation shall be reversible.
I suggest using 7-zip. It has portable version, can compress very good (or just copy without compression) all files recurse subdirectories and write output to single stream (stdout).
It has "-so" (write data to stdout) switch. For example,
7z x archive.gz -so > Doc.txt
decompresses archive.gz archive to output stream and then redirects that stream to Doc.txt file.
7z a -tzip -so -r src\*.cpp src\*.h > archive.zip
compresses the all *.cpp- and *.h- files in src directory and all it subdirectories to the 7-Zip standard output stream and writes that stream to archive.zip file (remove "> archive.zip" and intercept output by your program).
Why don't you use ZIP (disable compression if you want)? It's very standard, and support comes built into Windows. See Creating a ZIP file on Windows (XP/2003) in C/C++
Pure concatenation isn't reversible, because you can't know where to split it again. So you should use a directory of chunk sizes, such as exists in the ZIP and TAR formats.
Well, Shelwien's almost solved the issue.
The Tar version he proposes is "lean anough" (~120KB) and does not necessitate external DLL dependancies.
http://downloads.sourceforge.net/project/unxutils/unxutils/current/UnxUtils.zip
Unfortunately, it also has some problems of its own, such as no support for Unicode characters, interpreted escape sequence (so a directory name starting with t triggers a \t which is considered a tabulation), and a potential problem with pipe implementation under Windows XP (although on this last one it could come from the other program).
So that's a dead end.
A solution is still to be found...
[Edit] Shelwien just provided a solution by creating "shar", a tar replacement much smaller and much more efficient, without the limitations described above. This solve the issue.

Compress command results in corrupted zip file

I have a script set up to rotate some log files in windows, and as part of the process I'd like it to automatically compress the rotated file. To do this I use the command
compress source.file destination.file.zip
However, if I try to open the file, I get the message "The Compressed (zipped) Folder is invalid or corrupted"
I've tried compress with -Z, and I get the same message. What am I doing wrong?
compress output is not ZIP file format compatible, it uses the LZW algorithm.
The only way to "open" a compressed file is with uncompress or gunzip.
Windows ports of common Unix commands, including compress and gzip/gunzip available here.
EDIT: To produce ZIP files from the command line in Windows, you can use something like 7-Zip, which includes a command line application (7z.exe). The Unix commands linked above also include zip.exe for manipulating ZIP files from the command line.

Resources