Copying the GNU screen scrollback buffer to a file (extended hardcopy) - keyboard-shortcuts

How do I easily copy the GNU Screen scrollback buffer to a file? I.e., a more powerful version of the 'hardcopy' command?
In GNU screen, I can use "Ctrl + A Esc" to enter the scrollback
buffer. I could then mark the entire buffer and use "Ctrl + A Ctrl + ]" to paste it into an Emacs buffer, thus saving it to a file.
However, this is tedious. Is there a Screen command that'll simply copy the scrollback buffer to a file, like 'hardcopy' does for the visible portion of the screen?

To write the entire contents of the scrollback buffer to a file, type
Ctrl + A and :
to get to command mode, then
hardcopy -h <filename>
In older versions of screen, if you just do hardcopy -h, it just writes to the file -h. This was fixed in version 4.2.0, so hardcopy -h writes to hardcopy.N where N is the current window number.

Press Ctrl+A :bufferfile /tmp/somefile.txt ENTER, and then Ctrl+A >
This will write the current contents of the buffer to the named file.

TL;DR: ^A:writebuf <filename>
The OP seems to want a way to use the selected portion of the buffer you get when doing a ^A[ , selecting text using space as the start and finish, and then instead of using ^A] to paste, save the resulting selected portion of the buffer to a file.
This worked:
^A:writebuf <filename>
Note: one 'f' in writebuf

Try hardcopy -h to include the whole buffer.

This worked for me:
Enter edit mode (~) and type:
:hardcopy -h buff_file
It created a huge file, of which 98% was empty, but my logs were fully present in remaining 2%.

Ctrl + A, :, and issue the command 'log on'.
Or set it as the default in your .screenrc file as 'deflog on'.

Do Ctrl + A, H.
That saves the current screen into a hard copy file, e.g., hardcopy.0 for screen 0. It seems to be a quicker way than going Ctrl + A, : and typing the hardcopy command.

Related

Rename ttf/woff/woff2 file to PostScript Font Name with Script

I am a typographer working with many fonts that have incorrect or incomplete filenames. I am on a Mac and have been using Hazel, AppleScript, and Automator workflows, attempting to automate renaming these files*. I require a script to replace the existing filename of ttf, woff, or woff2 files in Finder with the font's postscriptName. I know of tools (fc-scan/fontconfig, TTX, etc) which can retrieve the PostScript name-values I require, but lack the programming knowhow to code a script for my purposes. I've only managed to setup a watched directory that can run a script when any files matching certain parameters are added.
*To clarify, I am talking about changing the filename only, not the actual names stored within the font. Also I am open to a script of any compatible language or workflow of scripts if possible, e.g. this post references embedding AppleScript within Shell scripts via osascript.
StackExchange Posts I've Consulted:
How to get Fontname from OTF or TTF File?
How to get PostScript name of TTF font in OS X?
How to Change Name of Font?
Automate Renaming Files in macOS
Others:
https://github.com/dtinth/JXA-Cookbook/wiki/Using-JavaScript-for-Automation
https://github.com/fonttools/fonttools
https://github.com/devongovett/fontkit
https://www.npmjs.com/package/rename-js
https://opentype.js.org/font-inspector.html
http://www.fontgeek.net/blog/?p=343
https://www.lantean.co/osx-renaming-fonts-for-free
Edit: Added the following by request.
1) Screenshot of a somewhat typical webfont, illustrating how the form fields for font family and style names are often incomplete, blank, or contain illegal characters.
2) The woff file depicted (also, as base64).
Thank you all in advance!
Since you mentioned Automator in your question, I thought I'd try and solve this while using that to rename the file, along with standard Mac bash to get the font name. Hopefully, it beats learning a whole programming language.
I don't know what your workflow is so I'll leave any deviations to you but here is a method to select a font file and from Services, rename the file to the font's postscript name… based on Apple's metadata, specifically "com_apple_ats_name_postscript". This is one of the pieces of data retrieved using 'mdls' from the Terminal on the font file. To focus on the postscript name, grep the output for name_postscript. For simplicity here, I'll exclude the path to the selected file.
Font Name Aquisition
So… running this command…
mdls GenBkBasBI.ttf | grep -A1 name_postscript
… generates this output, which contains FontBook's Postscript name. The 'A1' in grep returns the found line and the first line after, which is the one containing the actual font name.
com_apple_ats_name_postscript = (
"GentiumBookBasic-BoldItalic"
Clean this up with some more bash (tr, tail)…
tr -d \ | tail -n 1 | tr -d \"
In order, these strip spaces, all lines excepting the last, and quotation marks. So for the first 'tr' instance, there is an extra space after the backslash.
In a single line, it looks like this…
mdls GenBkBasBI.ttf | grep -A1 name_postscript | tr -d \ | tail -n 1 | tr -d \"
…and produces this…
GentiumBookBasic-BoldItalic
Now, here is the workflow that includes the above bash command. I got the idea for variable usage from the answer to this question…
Apple Automator “New PDF from Images” maintaining same filename
Automator Workflow
Automator Workflow screenshot
At the top; Service receives selected 'files or folders' in 'Finder'.
Get Selected Finder Items
This (or Get Specified…) is there to allow testing. It is obviated by using this as a Service.
Set Value of Variable (File)
This is to remember which file you want to rename
Run Shell Script
This is where we use the bash stuff. The $f is the selected/specified file. I'm running 'zsh' for whatever reason. You can set it to whatever you're running, presumably 'bash'.
Set Value of Variable (Text)
Assign the bash output to a variable. This will be used by the last action for the new filename.
Get Value of Variable (File)
Recall the specified/selected file to rename.
Rename Finder Items: Name Single Item
I have it set to 'Basename only' so it will leave the extension alone. Enter the 'Text' variable from action 4 in here.

Nano, writing lines

In Nano, when my text hits the end of the window, it starts a new line instead of continuing on the line I'm writing in. How can I change this?
Example:
This is a test, writing
next line
This is what I want:
This is a test, writing $next line
Add set nowrap to your .nanorc.
To disable line-wrapping permanently you can add set nowrap in your ~/.nanorc file.
To toggle between line-wrap / no-wrap in a file you can use the shortcut Alt, then $ (Shift + 4).
To open a file with line-wrapping disabled use -w or --nowrap (e.g. nano -w filename).

GNU screen: how to check current scrollback value?

In GNU screen, I know that I can change the scrollback (buffer size) using this command:
<Ctrl-a>:scrollback 10000
as well as adding this line in .screenrc:
defscrollback 10000
But How do I check what the current value is? (For clarification, looking at the .screenrc file and locating the line with defscrollback is not the solution I'm looking for.)
Thanks!
As soon as you enter scrollback mode (CtrlA then Esc), you should see a status line like
Copy mode - Column 71 Line 25(+3000) (80,25)
The 3000 is the scrollback size. As long as you're in scrollback mode, you can use CtrlG to see a shorter version of that status line. If you're no longer at the bottom, the +3000 will be changed to show how far you've scrolled back. It tells how many lines are available above the currently displayed region, so +0 means you've scrolled back all the way.
You can also issue the command Ctrl-A i to get the value of the scrollback size currently set for that particular window.

How to increase the size of the scrollback buffer in GNU screen

How do I increase the number of lines that I can view in screen?
I want to view the lines from the point when I ran screen -S <screen_name> to the current operation. For example, how would I increase the buffer length to around 50000 lines?
I have already tried ^a :scrollback <number> but it does not increases the lines I can reach in my current terminal.
You cannot retroactively increase the scrollback buffer length in the current session in order to recover old lines that have already been discarded. However, if you change the current scrollback parameter setting (C-a :scrollback <number>), it will add more space for future terminal output. You can also set the defscrollback parameter to affect the initial scrollback setting for new windows.
If you want to set the default for all windows of all new screen sessions, make a ~/.screenrc file with
defscrollback 50000
or, if you only want a big scrollback sometimes, put it in a separate file, like ~/screenrc-50k-scrollback and invoke screen like this:
screen -S <screen_name> -c ~/screenrc-50k-scrollback
Check the current scrollback buffer capacity with C-a i (the info command).
(22,1)/(25,40)+50000 +flow G0[BBBB] 0(bash)
^^^^^
Reference: GNU Screen manual, Scrollback section
I don't know if I understood correctly what you asked, but if so I think you can just increase the value of Lines of scrollback property you can find on the Window menu item on the left of your Session configuration.

Is it possible to direct your output file having the same name as input file, that is to overwrite?

I would like to overwrite the name of input file with the same name of output file owing to limited disk space that I have in my system. Is it possible? I know this is not recommended, but I have the input files already backup. I will have a loop in a shell to do the cut command.
#!/bin/bash
for i in {1..1000}
do
cut --delimiter=' ' --fields=1,3-7 input$i.txt > input$i.txt
done
You could always use a temporary file to which you redirect, and then when you're sure everything went fine, you rename it to the original file.
some gnu utils commands have a -i option (such as sed) that allow you to change a file in place .....most of file filtering and editing (like cut) can be done using sed.
The shell will parse the command and handle the redirections first. When it sees "> afile" it will truncate "afile" and open it for writing. Your data is now destroyed. Then the shell hands the filename to cut which now has nothing to read.
This is how I learned:
some | pipeline < my_file > my_file.tmp
ln my_file my_file.bak # this is a hard link
mv my_file.tmp my_file
That keeps the original data in place for as long as possible.
If you're having disk space issues, you will have to read the input file into memory entirely.
In case of very limited disk space (disk quota) you could try to place a compressed source file in ram (/dev/shm) and use that as the source (uncompressing it to stdout and piping that to your script).