The reason of starting a line with colon ":" in zsh_history file - format

I'm using the zsh history plugin, which adds the timestamp of the command I entered. The raw file of the .zsh_history text file looks like below:
: 1582469132:0;jupyterlab
: 1582469132:0;jupyter notebook
: 1582469132:0;jupyterlab
: 1582469132:0;jupyter lab
: 1582469132:0;jupyter notebook
: 1582469132:0;ls
I just don't understand the reason for using this format that why every line item starts with a colon :?
I'm pretty sure this plugin is not the only one using this format. I've seen SWIFT messages using this format and some other file which I couldn't remember the name.

I'm not positive, but I believe the leading colon allows you to execute the history file as a script.
: is a do-nothing command: it ignores its arguments then completes with an exit status of 0. In this case, the argument is the string <timestamp>:0; the semicolon is a command terminator.
You can try it out at the prompt:
% : 1235:0;echo hello
hello
Thus, executing this file as a script would have the same affect as executing
jupyterlab
jupyter notebook
jupyterlab
jupyter lab
jupyter notebook
ls
It's unlikely you would want to execute an arbitrary history file as a script, but a file containing a specially crafted history could be useful.

Related

How to pass a letter to the abaqus datacheck using here strings through a bash script?

This question is about passing input to commands inside a bash script. I am working on Ubuntu 18.04. I am running the following command several times inside a folder :
abaqus datacheck job=Job input=inputfile.inp user=umat.f
Every time I do it asks me if I want to overwrite the existing job files (y/n) ? and I type y and press enter. I was able to automate this last step using the following tweak with a here string on the terminal prompt :
abaqus datacheck job=Job input=inputfile.inp user=umat.f <<< 'y'
But when I include this in a bash script as part of a larger automation file, it doesn't work. This command using a here doc doesn't work inside the bash script either :
abaqus datacheck job=Job input=inputfile.inp user=umat.f << EOF
y
EOF
What did work : I put the single character y inside a text file called affirmative and passed that as a here doc :
abaqus datacheck job=Job input=inputfile.inp user=umat.f << affirmative
Could someone please tell what I am doing wrong in the bash script when trying to use a simple here doc or a here string ? I don't want to have a text file in my folder just for one character.
Is it really important to be limited by a bash script? If not, you can use this solution with python scripting:
1. Launching the bash command via subprocess
import subprocess
my_cmd = 'abaqus job=Job-1 input=inputfile.inp user=umat.f'
proc = subprocess.Popen(
my_cmd,
cwd=my_working_dir,
stdout='my_study.log',
stderr='my_study.err',
shell=True
)
2a. Running different jobs using different job names (Job-1, Job-2)
and deleting old ones with a delay (e.g. deleting 'Job-1' while 'Job-3' has started)
2b. Writing to the command line
By adding an option stdin=subprocess.PIPE to your subprocess.Popen call and using proc.stdin.write("y") command after
Personally, I like more the first option as it seems more predictable to me.

Bash adding unknown extra characters to command in script

I am currently trying to create a script that executes a program 100 times, with different parameters, typically pretty simple, but it's adding strange characters into the output filename that is passed into the command call for the program, the script i have written goes as follows
#!/bin/bash
for i in {1..100}
do ./generaterandomizedlist 10 input/input_10_$i.txt
done
I've taken a small screenshot of the output file name here
https://imgur.com/I855Hof
(extra characters are not recognized by chrome so simply pasting the name doesn't work)
It doesn't do this when i manually call the command issued in the script, any ideas?
Your script has some stray CRs in it. Use dos2unix or tr to fix it.

How to paste multi-line input into Jupyter console?

The %paste magic for pasting multi-line input works with IPython 2, but fails with Jupyter console (on Mac OSX El Capitan).
~ > jupyter console
Jupyter Console 4.1.0
In [1]: %paste
ERROR: Line magic function `%paste` not found.
In [2]:
Going through the output of %lsmagic that lists all the magic commands indeed doesn't show %paste.
I tried to directly paste, but the indentation gets messed up, so something like %paste is needed apparently. Checking the official documentation (updated just 5 days ago) the word "paste" is not even mentioned.
So, how do you paste multi-line input to the console?
Ok. Found the solution. Jupyter console has a %cpaste magic that behaves a little different than the previous %paste but get the job done.
%cpaste:
Paste & execute a pre-formatted code block from clipboard.
You must terminate the block with '--' (two minus-signs) or Ctrl-D
alone on the line. You can also provide your own sentinel with '%paste
-s %%' ('%%' is the new sentinel for this operation).
The block is dedented prior to execution to enable execution of method
definitions. '>' and '+' characters at the beginning of a line are
ignored, to allow pasting directly from e-mails, diff files and
doctests (the '...' continuation prompt is also stripped). The
executed block is also assigned to variable named 'pasted_block' for
later editing with '%edit pasted_block'.
You can also pass a variable name as an argument, e.g. '%cpaste foo'.
This assigns the pasted block to variable 'foo' as string, without
dedenting or executing it (preceding >>> and + is still stripped)
'%cpaste -r' re-executes the block previously entered by cpaste.
'%cpaste -q' suppresses any additional output messages.
Do not be alarmed by garbled output on Windows (it's a readline bug).
Just press enter and type -- (and press enter again) and the block
will be what was just pasted.
IPython statements (magics, shell escapes) are not supported (yet).
See also
--------
paste: automatically pull code from clipboard.
Examples
--------
::
In [8]: %cpaste
Pasting code; enter '--' alone on the line to stop.
:>>> a = ["world!", "Hello"]
:>>> print " ".join(sorted(a))
:--
Hello world!

External output to vim buffer AFTER command completes

I'm currently using gVim on Windows 7
Running a command like:
:r! racket %
I am able to successfully read in the desired output about half of the time. The rest of the time, nothing is read. It seems to be an issue with vim reading in the output before the shell execution has terminated and actually generated some output.
Any ideas?
From :help :r!
:[range]r[ead] !{cmd} Execute {cmd} and insert its standard output below
the cursor or the specified line. A temporary file is
used to store the output of the command which is then
read into the buffer. 'shellredir' is used to save
the output of the command, which can be set to include
stderr or not. {cmd} is executed like with ":!{cmd}",
any '!' is replaced with the previous command |:!|.
It could be that you need to set :help shellredir to include stderr.

Simple shell script doesn't work like command line?

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 ?).

Resources