When running a shell command without redirection, I sometimes in hindsight want to process the output I see on screen.
I often want to "grep" the output of a console in hindsight. I might not be able to run the command again with proper redirection: (The command might take a long time to run. The command might have produced side effects).
Is there some shell wizardry which I could use to: "Grep the last 100 lines of output in the terminal", without re-executing the command again with a redirect?
My current solution is to scroll up manually, and copy paste the last lines of output into a text file. I would prefer a fully scripted solution instead...
Is there some shell wizardry which I could use to: "Grep the last 100 lines of output in the terminal", without re-executing the command again with a redirect?
No.
My current solution is to scroll up manually, and copy paste the last lines of output into a text file. I would prefer a fully scripted solution instead...
Exactly, you have to use the program that is used to view the output, be it a graphical terminal in a graphical environment. Some such terminals allow to save the current "state" of terminal output to a file. Next time - use tmux or screen - i.e. a program that simulates the terminal.
Related
Here have been already quite a few questions and answers about cropping documents with Ghostscript.
However, the answers are not matching my exact needs and are still confusing to me.
I expected that there would be a single option e.g. "-AutoCropToBBox" or something like this.
For clarification, as a bounding box, I understand the smallest rectangular box which contains all (non-white(?)) printed objects completely.
Furthermore, I want/have to use a printer port redirection (RedMon) to generate a cropped PDF via printing to a Postscript-printer from basically any application.
So, under Win7/64bit, I set the redirected port properties:
Redirected port properties Win7/64bit
The output is redirected to
C:\Windows\system32\cmd.exe
The arguments for the program are:
/c gswin64c.exe -sDEVICE=pdfwrite -o -sOutputFile="%1".pdf -
"%1" contains the user input for filename. With this, I get a full-page PDF. Fine!
But how to add the cropping options?
Additional question:
If I have a multipage document will such an (auto-)cropping be individual for each page? Or would there be an option to keep it all the same e.g. like the first page or like the largest bounding box of all pages?
Another related issue:
the window for prompting for the filename is always popping up behind the application I am printing from. Any ideas to always bring it to the front?
Another question:
There is the Perl-script "ps2eps" and program bbox.exe (see http://ctan.org/pkg/ps2eps). It's said there that Ghostscript (or ps2epsi) is occationally(?) calculating wrong bounding boxes. Is this (still) true?
Thanks for your help.
Well your first problem is that PostScript programs are normally written to expect to be rendered to a specific media size, and are usually not tightly bounded to it. White space is important for readability.
So ordinarily the PostScript program you generate will request a specific media size, and the interpreter will do its best to match that. If it can't match it then it will use a strategy to try and get as close as possible, and scale the entire content to fit that media.
You can't expect the printer to perform any of those things if it doesn't know the required size until its finished, and you can't be certain of the bounding box until you have rendered all the marking content. It is true that some files generally EPS files have a %%BoundingBox comment but.. that's a comment, it has no effect in PostScript, its there for the benefit of applications which don't want to interpret the PostScript.
So that's why the simple switch you want isn't there, it would break the interpreter's normal functioning, for rendering.
So, the first thing you need to do is determine the bounding box of the content. You can do that, as Stefan says, by using the bbox device. And on that note, as far as I know the bbox device produces accurate output. If it does not then we would appreciate a bug report proving it so we can fix it. If people don't report bugs how are we supposed to know about them ? Its disappointing to see someone spreading FUD instead of helping out with a bug report.......
ps2epsi isn't Ghostscript, its a crappy cheap and cheerful script, I wouldn't use it. However..... If the original PostScript leaves stuff on the stack then it will end up as a corrupted (or invalid) EPS file and the original PostScript should be fixed before trying to use it as it will break any PostScript program that tries to use it (eg if you include the EPS in a docuemnt and then print it).
So if you are using Ghostscript, and you want to take a PostScript program and get an EPS out of it, use the eps2write device. It won't have a preview bu frankly who cares.
Now if I remember correctly the bbox device (and eps2write) record all marking operations, you can't simply record all the non-white marking operations; what if the white overwrites an existing mark on the page ? What if the media is not white ? Note that if you render to a PNG with Ghostscript, the untouched portion of the output is transparent, whereas white marks are not.
So the bbox is the extent of all the marking operations, regardless of the colour. The only other way to proceed would be to render the content and count the non-white pixels. But that only works at a specific resolution, change the resolution and the precise bounding box may change as well.
Once you have the Bounding Box you can tell Ghostscript to use media that size. Note that you will almost certainly also have to translate the origin, as its unlikely that the content will start tightly at the bottom left corner. You will need -dDEVICEWIDTHPOINTS and -dDEVICEHEIGHTPOINTS to set the media size, and you will need to use -c and -f to send PostScript to alter the origin appropriately. In simple cases an '-x -y translate' will suffice but if the program executes initgraphics you will instead have to set a BeginPage procedure to alter the initial CTM.
If you set the media size with -dDEVICEWIDTHPOINTS etc then all pages will be the same size. If you don't want that then you need to write a BeginPage procedure to resize each page individually (you will also need to hook setpagedevice and remove the /PageSize entries from the dictionary.
I've no idea why Windows is putting the dialog box behind the active Window, it seems to have started doing that with Windows 7 (or possibly Vista). I don't see any way to alter that because I'm not sure what is generating the dialog.....
Personally I would suggest that you try the 2-step approach of running the original through Ghostscript's eps2write device and then take the EPS and create a PDF file using the pdfwrite device and the -dEPSCrop switch. Double converting is bad, but other solutions are worse. Note that EPS files cannot be multi-page, so you will have to create 'n' EPS files from an n-page PostScript program, and then supply a command line listing each EPS file as input to the pdfwrite device.
Take an example file and try this out from the command line before you try scripting it.
As I understood from #KenS explanations:
the way eps2write works, it may not or will not or actually cannot result in the minimum possible bounding box
it needs to be a 2-step process via -sDEVICE=bbox
So, I now ended up with the following process to "print" a PDF with a correct minimum possible bounding box:
Redirected Printer Port to cmd.exe
C:\Windows\system32\cmd.exe
Arguments for the program:
/c gswin64c.exe -q -o "%1".ps -sDEVICE=ps2write - && gswin64c.exe -q -dBATCH -dNOPAUSE -sDEVICE=bbox -dLastPage=1 "%1".ps 2>&1 >nul | perl.exe C:\myFiles\CropPS2PDF.pl "%1"
Unfortunately, it requires a little Perl script (let's call it: CropPS2PDF.pl):
#!usr/bin/perl -w
use strict;
my $FileName = $ARGV[0];
$/ = undef;
my $Crop = <STDIN>;
$Crop =~ /%%BoundingBox: (\d+) (\d+) (\d+) (\d+)/s; # get the bbox coordinates
my ($llx, $lly, $urx, $ury) = ($1, $2, $3, $4);
print "\n$FileName: $llx, $lly, $urx, $ury \n"; # print just to check
my $Command = qq{gswin64c.exe -q -o $FileName.pdf -sDEVICE=pdfwrite -c "[/CropBox [$llx $lly $urx $ury]" -c " /PAGE pdfmark" -f $FileName.ps};
print $Command; # print just to check
system($Command); # execute command
It seems to work... :-)
Improvements are welcome.
My questions are still:
Can this be done somehow without Perl? Just Win7, cmd.exe and Ghostscript?
Is there maybe a way without writing the PS-File to disk which I do not need? Of course, I could also delete it afterwards with the Perl-script.
If you open a big java file, scroll to 'somewhere' and make a change. Then close the file and re-open it, Intellij will open it at the last point that you made the change. This is annoying, can it be changed so it always opens the file at the top like most file reading applications do
I don't really remember seeing such an option, but you can work around with some small tricks.
1) include line number of the file, eg to open MyUI at line 10: CTRL + N & type myui:10
2) navigate to symbol, et to navigate to method init of MyUI: CTRL + SHIFT + ALT + N & type myui.init
This same misfeature annoyed me to the point of doing something about it, as I prefer to open files by double-clicking them in the Project tree (which doesn't present the option of typing in a line number). Also, it bothers me to be typing in line numbers on every single file option simply to get the text editor to not jump to wherever I was editing six months ago.
Sadly, there's still no option to toggle this behavior. (JetBrains really, really doesn't like it when users prefer simpler behavior than their flagship defaults.) But it's very easy to strip the "last edited position" history out of the saved workspace.
Optional first step: If you have more than one workspace, you need to find its configuration file. Wherever you designated the project root location should contain a .idea subdirectory with a workspace.xml file, for example $HOME/IdeaProjects/MyProjectName/.idea/workspace.xml. There will be a ProjectId key and some "nonsense looking" value, for example
<component name="ProjectId" id="wZadhKS8vnOD4GBBT2Pz93rDw" />
You'll need that unique ID.
Actual steps:
Exit IDEA. You can't do this while the IDE is running.
Go to your personal IDEA directory. This can vary based on version; for me it is currently %HOME%/.IdeaIC2019.3. It will have a config/workspace subdirectory containing an XML file for each of your workspaces, named after the ProjectId above. For example,
$HOME/.IdeaIC2019.3/config/workspace/wZadhKS8vnOD4GBBT2Pz93rDw.xml
For 2020.1 and later, this location has moved; for me the default is now %APPDATA%/JetBrains/IdeaIC2020.1 and there is no config subdirectory, so: C:/Users/me/AppData/Roaming/JetBrains/IdeaIC20201./workspace instead.
That XML file contains the saved last-edit positions in a node like this:
<component name="editorHistoryManager">
this is all the stuff that causes annoyances
</component>
Make a backup copy of the wZa...3rDw.xml file, whatever it's called for you.
Use your favorite programmatic XML editor tool to remove that node. For example:
xmlstarlet ed --omit-decl -d '//component[#name="editorHistoryManager"]' wZa...3rDw.xml > tmp
mv tmp wZa...3rDw.xml
The next time IDEA is launched, all files will open at their beginning, the way God and nature intended.
For bonus points, automate the above in a script that runs behind the scenes as appropriate. :-)
IDEA does something a little unusual with its XML involving whitespace, and tools like XMLStarlet often do something else. As XML is whitespace agnostic this makes no difference at runtime, but it does mean that if you want to compare for correctness or you're keeping the IDEA configuration in revision control, there will be a lot of extraneous "churn" in the diffs. If this causes too much noise, you can augment step (4) to something like
xmlstarlet .... | sed -e 's#"/>$#" />#' > tmp
to insert extra whitespace back, in most of the places where IDEA had originally put some. (I didn't test this heavily, as the lack of whitespace isn't important to me or to the IDEA runtime. It would have been nice to have a cleaner diff, but whatever.)
Caveats: As IDEA can save its config in either a directory-based layout, or in a all-in-one-file layout, the steps to find the workspace config file may vary wildly. What I wrote above works for the default directory-based layout.
this time I'm fighting against a .txt file which doesn't want to be (programmatically) set to be printed in Portrait-mode instead of Landscape-mode (which is the default apparently).
Thing is I know how to do that with application like Word or Excel, but sadly enough I'm working on a device that has no Office at all.
I'm not providing any code at all since my problem is pretty straightforward, and I think I need a simple command in order to solve it. What I basically (programmatically) do in my subroutine is:
Open the file as #1 (I know this appears so '80, but I don't want to modify an up-and-running system, potentially having errors show up)
Write text to the file
Close #1
Save the file
Call text editor shell to show the file to the user
How can I then automatically set the print format to Portrait?
P.s.= I do not have the possibility to insert a userform or an object to print the txt file in "special ways", the user has to print the file from txt editor itself (wordpad just in case)
First to state the obvious: there are no print settings stored in text files (or indeed anything else except for the text). Print settings would be controlled within whatever you are using to print - in this case Notepad or Wordpad.
There are only very limited command line switches for Notepad and Wordpad, which unfortunately don't include page setup. In theory you may be able to automate setting portrait using SendKeys (see here and here) but if it is possible at all it's likely to be difficult and unreliable (focus and timing are two issues).
I can't see a good way round this within the parameters of your question. Adding an object within your application would probably have been the best solution. You might try looking for an alternative text editor you could install that is easier to automate. The only other alternative might be to set defaults within the printer drivers and hope that those stick when the user opens Notepad.
We have to do a comparison of about 1500 PDF's in one folder with 1500 PDF's in another to check for visual differences.
We have found DiffPDF(and comparePDF command line version) for Windows which is a lot faster than our automated Acrobat Pro comparisons.
So far I have used:
comparepdf -v=2 =c=a old.pdf new.pdf
but the problem with this is that it just returns "these files are different". Does anyone know of any way to save the output from command line? You can do this from the GUI but that would mean using something like TestCOmplete to automate it :(
Or are there better ways of doing a comparison of 2 PDF's visually- with output/highlighting/
Bonus points for C# .net libraries.
You could have a look at these answers to similar questions:
PDF compare on linux command line
How to compare two pdf files through command line
How to unit test a Python function that draws PDF graphics?
However, I have no idea if any of these would be performing faster than what your automated Acrobat Pro comparison does... Let me know if you found out, will you?
Shortcut:
For simplicity, let's assume your input files to be compared are similar enough, and each being only 1 page. (For multi-page input expand the base idea of this answer...)
The two most essential commands any such comparison boils down to are these:
compare.exe ^
%input1% ^
%input2% ^
-compose src ^
%output%.tmp.pdf
and
pdftk.exe ^
%output%.tmp.pdf ^
background %input1% ^
output %output%.pdf
The first command generates a PDF with all differential pixels colored in red. (A default resolution is used here, 72 dpi. For a more fine-grained view on pixel differences add -density 200 (that will mean: 200 dpi) or higher -- but your processing time will increase accordingly as will the disk space needed by the output...)
The second command tries to merge the resulting PDF with a background taken from ${input1}.
Optionally, you may add -verbose -debug coder after the compare command for a better idea about what's going on.
compare.exe is a commandline tool from the great, great ImageMagick family of utilities (available for Linux, Windows, Unix and MacOSX). But it requires a Ghostscript installation to use as a 'delegate' in order to be able to process PDF input. pdftk.exe is also a commandline utility, available for the same platforms. Both a Free Software.
After the first command, you'll have an output file which has only red pixels where there are differences found on the page.
After the second command, you'll have an output with all red 'diff' pixels in the context of the first input PDF.
Example output:
Here are screenshots of two 1-page PDF files with differences in their content:
Here are screenshots of the output produced by the two commands above:
The left one shows the intermediate result (after first command), with only the difference pixels displaying as red (identical pixels being white).
The screenshot on the right shows the red difference pixels, but this time with the input PDF file number 1 as a (gray) background (after second command).
(PDF input files courtesy of Mark Summerfield, author of the beautiful DiffPDF tool.)
I had the same problem, diffpdf is quick and nice but GUI only.
[comparepdf] is console one but reports only exit code (no diff itself).
[diff-pdf] has both console mode and diff.pdf output but it is slow and output is not friendly.
I have tried to add the required code to diffpdf,
you can find it here: http://github.com/taurus-forever/diffpdf-console
I'm trying to make an autohotkey script so I can drag and drop movie files into autohotkey for it to put it into handbrake's queue to be converted into iphone format.
I just started with autohotkey and have no idea on how to record a macro like that. Can anyone point me the right way or maybe does anyone have a script like that to share?
Handbrake comes with a Command Line program (default path = C:\Program Files\HandBrake\HandBrakeCLI.exe)
That would probably be your best bet versus trying to make a macro to interact with the GUI version of Handbrake. If you only wanted to do one at a time a simple DOS batch script would allow you to drag and drop files:
1) Open Notepad
2) Paste the following text:
"C:\Program Files\HandBrake\HandBrakeCLI.exe" -i %1 -o %1.mp4 -e x264 -b 2000 -B 128 -X 480
3) Save the file as HandbrakeCLI.bat (or anything else you want as long as it ends in .bat)
4) Place that where the video you want to convert is located and drag the video file onto the .bat file. A DOS window should pop up and start converting the video.