I have a batch file that has been aesthetically formatted to display information center console at variable dimensions. In order to achieve this I have used the echo command followed by a period to produce white-space, or just empty space, above and below the content. See the left side of the picture
This works fine for "frames" that switch once per second, but when I remove the the delay it becomes obvious that each 'echo.' is producing one line of white space at a time, creating a rapid scroll, rather than a seamless transition. See the right side of the picture
[]
I've seen a cmd bouncing ball animation on a DIY website, where one of the commenters used a lot of for loops to produce a box with a ball bouncing inside of it. He managed to avoid the scrolling. But that code looked very complicated. I'm not ready to decipher it. But if there were a way to make command prompt produce two ore more lines of white space simultaneously, rather than procedurally, that would be of more use to me. More specifically the ability to produce, as a single instance of output, a whole block of text would be what I am looking to do.
If you want to print on the same line, use echo -ne with \r, which is the return carriage (ie. Print next character at the beginning of the line). Google it for more information.
If you are trying to add intervals between your prints, you can use sleep.
Animation is done through careful use of \r to start writing the same line(s) over again. This can be done with a single or multiple echos.
Related
I have a script which is for running as a first run script on different machines and I don't know ahead of time what the width/height of the monitors will be. What I hoping to find is a command like printf "\033[8;(width);(height)t" which is more universal and will expand the terminal to maximum no matter which size monitor is connected to the computer. I had an escape sequence that worked great, but I lost the script along with the code when one of my drives died (I know, backup, backup, and backup again) and can't seem to find that fix again anywhere.
Using the printf "\033[8;(width);(height)t" escape code sequence works if I know in advance what the height and width of the maximized monitor dimensions are (for instance using printf "\033[8;58;238t" will work on my 1920x1080 monitor just fine and will expand as expected) but it is not enough for a larger monitor. Using tput cols and tput lines will give me what the current window dimensions are, but not the maximum dimensions.
I know I can use the keyboard and mouse to do this, but I am strictly looking for something that will expand the window without any other input or key presses, if for no other reason than knowing how to do it and making it work. This needs to execute at the beginning of a bash script on a fresh Ubuntu flavor installation (the script does unique installations and updates). It might be able to work if I could figure out how to get the maximum terminal size possible of a screen into a variable to be used in the code mentioned above.
I have tried echo -ne '\e[9;1t' and printf '\e[9;1t', also echo -ne '\e[10;2t' and printf '\e[10;2t' escape codes to no avail, mentioned at https://terminalguide.namepad.de/seq/ (Control Characters and Escape Sequences) on pages "Alias: Maximize Terminal" and "Maximize Terminal Window". This is one of the few references I can find. Any searching of various ways to ask this question doesn't seem to yield any results and they all seem to rely on knowing ahead of time what the maximum dimensions can be.
Any hints of what I can use for this would be helpful, thank you.
Set the size to a number that is guaranteed to be larger than any existing screen. Pad it some to accommodate for rapidly increasing screen resolutions:
printf "\033[8;99999;99999t"
The window manager should truncate the size to the maximum available area.
I have started to use tmux and noticed that the lines that seperate the different panes are not entirely straight, instead there are small bumps. I think it might have something to do with the font, my thought is that characters from one "character-field" are overlapping into the next, which creates the little bumps. Does anyone know how I can fix this and get a straight line without bumps?
The font I use: Menlo
example of the bumpy lines
The problem was actually the terminal emulator I used, Alacritty, which lets some characters reach outside of their cell. To solve this issue, I switched to Kitty, which has better support for preventing characters from overflowing into other cells.
I'm using the output of the excellent package icdiff (https://github.com/jeffkaufman/icdiff) to check for differences between updated iterations of files. I'd like to parse out just the significant differences though. From the package --help I can't see any in-built options (and for full disclosure I've 'cross posted' at the github issues page to see if it can be added or I've missed something).
This has got me wondering whether a hacky solution might be to parse out the lines by their colour, since they are also colour coded by 'severity of difference'. Is this at all possible in bash? (Alternative approaches are welcome too!)
Here's a sample of the output (I can only think to add a picture here since the markup wouldnt show colour). I'd like to get just the lines where the whole line is solid red/green for instance. Excuse some of the screen wrapping, my monitor isn't wide enough and the text is small enough already.
with GNU Grep, for example
grep -Po $'\e\[31m\K.*(?=\e\[\d+m)'
to extract text in red,
\K to keep the left outside match, like a lookbehind
(?=..) lookahead assertion 0 length match
you can grep on the ANSI escape sequences, e.g. (with 31 for red):
grep '^[\[31m' # make the escape character (^[) by typing ctrl+v ESC
but you need to make sure your output stays colored if it is not sent to a terminal : (many programs will make their output B&W when output is not a terminal. - you can check it with less, which will show you the escape sequences)
I have a HTML element that contains the text Snow-boarding, the container element doesn't have enough space to fit the text in one line so I need it to break in two.
In Chrome this is done automatically (I guess it assumes it's two words and leaves "Snow-" in the first line and "boarding" in the second).
In Firefox however it just leaves it in one line and it extends beyond the container. I was thinking on using the CSS property "word-wrap", which does break the word, but it doesn't break it in the dash (it leaves "Snow-boardi" in one line and "ng" in the other).
Here's the jsFiddle: http://jsfiddle.net/jSrLb/5/
Any way around this?
Thanks
I am in the process of writing a text editor. After looking at other text editors I have noticed that a number of them refer to a "soft" versus "hard" wrap. What is the difference? I can't seem to find the answer by searching.
A hard wrap inserts actual line breaks in the text at wrap points, with soft wrapping the actual text is still on the same line but looks like it's divided into several lines.
It's usual for text editors to auto-wrap text into paragraphs with hard newlines, but it's less common for the text to be re-flowed into a nice paragraph if you come back later and edit/add/remove words later on. (You can do this manually in emacs with M-q.)
This is rather annoying, since obsessive compulsive people like me then go back and have to manually re-insert the hard breaks at the appropriate points.
On the other hand, soft wrapping is annoying because most all command line tools use line-based diff-ing (version control is where this becomes most noticeable to me). If you've got a 1/3-page paragraph that's soft wrapped and fix a typo, it's basically impossible to see where the change is in a regular diff output or similar.
soft : The text in the textarea is not wrapped when submitted in a form. This is default
hard : The text in the textarea is wrapped (contains newlines) when submitted in a form. When "hard" is used, the cols attribute must be specified
Reference: W3Schools