Difference between iTerm2, zsh and oh-my-zsh - zsh

I have been using the default bash of linux for over 1 year and one of colleague recommended me switch over to using iTerm2 alongwith zsh and oh-my-zsh. He also recommended this post to install and configure those :
https://www.freecodecamp.org/news/how-to-configure-your-macos-terminal-with-zsh-like-a-pro-c0ab3f3c1156/
When i asked what are they the answer he gave me was kind of confusing, so i ask you overlords kind do tell mewhat actually those are and if you have some insights about what actually a bash is, i would be happy to learn that too :)
Thank you all
Pawan

When you are at a command line, typing in commands and reading output you are working in a program called a terminal (or console on windows). The terminal is taking your commands and forwarding them to a program, called a shell, who's job is to actually execute the commands you type in to the terminal and possibly print some output. The output from the shell is then displayed in your terminal window.
The terminal is like the web browser and the shell is like the javascript engine. Your browser takes your input (click, keypresses, mousemoves) and sends them along to javascript which processes those actions and the browser displays the results.
iTerm2 is a terminal emulator meant to be a replacement for macOS terminal and is far more feature rich. It's the terminal program providing you with a command line interface.
ZSH is a specific shell, as is bash, the same way linux is a specific operating system. There are different shells that provide different syntax, features and functionality. There's bash, cshell, fish, powershell, zsh and others.
Installing ZSH, you are essentially downloading a new program and telling your terminal to use that program (say, instead of bash) to process the commands and run scripts.
oh-my-zsh provides a way of managing your zsh configurations, themes and plugins to extend the look and functionality of your shell.
I can't reccomend this setup enough- it's like the cadillac of command lines. You have a good friend there.

Related

Is there any way to call Inform7 from the command line?

is there any way to play inform7 from the command line? I'd like to write some automated test script that plays the play with certain commands and don't want to do it manually. Is there any way to do that?
This is easiest to do with the CLI Linux package of Inform 7. It contains a perl CLI script you can run, but you may also like to consider this alternative script I wrote: https://github.com/i7/kerkerkruip/blob/master/tools/build-i7-project
You can invoke this with
build-i7-project -p "Project Folder"
(Leave off the .inform.)
You can also run the binaries which are installed with the IDE packages by themselves instead of installing the CLI Linux package. The command line options are probably mostly the same in other operating systems, but you may need to change them slightly. If you can't get it to work, compare with what the Inform 7 IDE says when you build with it.
If what you really want to do is periodically run some test scripts that verify that your work is still performing as expected, then Inform 7 has the capability do do that from within the IDE. Take a look at chapter 24.2 of Writing with Inform for details. In combination with good use of the Skein, this should handle the more common unit-testing requirements.
Of course, if you're doing something more outré, running bash scripts from the command line may wind up being the way to go. Still, don't do any more work than you have to. :)

Run .bat script in unix

I have one .bat script on my windows share that is mounted to my UNIX machine. Bat script is set to make file transfer between 2 windows shares, but I would like to trigger this script from a unix machine if that is possible. I was reading that you can do it with wine or dosbox, but I don't have that installed on my unix. Is it possible to resolve this problem with some additional .sh script that will trigger my .bat script correctly?
Thank you in advance.
Best regards.
You cannot run a .bat script on a Unix machine for several reasons :
Unix has not the same commands (on the command line) as Windows. The POSIX standard defined a set of commands, if you use them you'll be portable on various POSIX systems (but not on Windows); for example to list a directory, you'll use DIR on MSDOS and Windows but ls on Unix and POSIX; to copy a file it is COPY on MSDOS and Windows but cp on Unix and POSIX; etc....
Unix has not the same command interpreter as Windows. The POSIX standard and the Unix tradition provides a Unix shell and POSIX has standardized /bin/sh (a.k.a. POSIX shell). Windows has CMD (inherited from MSDOS) and PowerShell.
The way of interpreting commands is different (on Windows look also into PowerShell, which I don't know). On Unix it is the shell (not the invoked programs) that is expanding your command and globbing. See this answer for more. The notion of current working directory is different.
the operating system concepts are (slightly or significantly) different on Windows and on Unix or POSIX. For example, files, directories, processes, libraries are different (for example, a file can be written by a process and removed by another one on Unix and it can have several names on Linux thru hard links), .... etc.... You could read Operating Systems: Three Easy Pieces for an overview.
the Unix philosophy is not (always) applicable to Windows.
So you need to study Unix (or POSIX) and write your own shell script from scratch. Don't try to "translate" a bat script to a Unix shell script, but redesign it entirely (starting from the problem you want it to solve).
(and Wine or DosBox is not helpful in your case)
Read also about SCP and perhaps FTP. Perhaps using some distributed version control system like git could be relevant for you (e.g. to share scripts, source code, etc...).
If you need to run remotely some Windows .bat script on a distant Windows machine (e.g. from a Unix machine), you should use some remote command running service (that is, find and use some equivalent of SSH service on Windows, and use the corresponding client on Unix). See this.
So if you need to remotely run on a Windows server something (e.g. some program, some script, some command) from a Unix machine you should ask a different question (or at least improve a lot the current one).
Read about the client-server model and about application layer to use the correct terminology. You should name what protocol, server, client, service you want to involve. Nothing is magically "triggered" without using them.
PS. I'm using Unix since 1987, Linux since 1993. I never used Windows.

Is there a reliable directory watcher that can be used to run shell commands on any modification?

I am looking for a tool (preferably X platform) that can watch a directory's entire tree and run shell commands when it happens.
I have tried many tools prior, such as fswatch, chokidar, findr...
But they have quirk issues, e.g. some of these command terminates when a file in the watched directory is removed.
Is there a tool that I am missing on? It would be best if the tool is X platform.
https://facebook.github.io/watchman/docs/watchman-make.html
(disclosure: I'm the creator of Watchman)

Looking for a pv or dialog equivalent

I am working with network shell (nsh; bmc software) I believe it is based on zsh 4.3.4. I have written a script that connects to a list of variable solaris machines and runs numerous commands and then creates some local directories and files based off of those commands.
I am looking for a way to display the script's progress as it can take some time depending on the number of servers. I have been told by others I need to utilize pv or dialog. However, in nsh when attempting to run these commands I get "command not found." It could be a limitation of nsh as well.
As a simple example, I want to see the progress of the following:
for i in $(cat serverlist.txt)
do
nexec -i $i hostname >> hosts.txt
done
Of course my script is a lot more complex than this but I cannot seem to get it working correctly as pv and dialog are not available. Also I know I should be using read -r to truncate the file, but appears not to work correctly either.

set environment variables for system() in R?

I've been using R in Ubuntu to make system calls using system() for things like spinning up Amazon EC2 instances, managing files on S3, etc. If I start R from the command line everything works fine. But if I start R from a script using Rscript, or from ESS, I have issues with environment variables not being set.
I think this is an issue with me not properly grokking where to set environment variables in Ubuntu. I thought the "right place" (for some definition of "right") was to set user environment variables in ~/.bashrc. This is where I set things like export EC2_HOME=/home/jd/ec2 but when I execute R from ESS and make system calls, the .bashrc script is not being run. I've tried Googing about and I see many an exegesis on environment variables in Ubuntu, such as this one. My knee jerk reaction is to try each recommendation in the aforementioned thread and stop giving a shit as soon as one of the options works. But then I end up with non-standard settings which bite me in the ass later.
So how should I set environment variables so that they are properly set when I run a system() call in R?
You can try to set them in R itself using Sys.setenv.
I think you are confusing the issue. I fear this may be about login shells versus non-login shells. See the bash manual page for the fine print ... which has driven me bonkers in the past.
That said, if you can set environment variables system-wide, you have a few options:
/etc/environment is a very good place as it is shell-agnostic should you ever use a different shell
for login versus non-login shells, the one way to get complete control that I found suitable was to put my changes into something like ~/.local_bashrc
the add . ~/.local_bashrc from and and all of
~./bashrc
~/.bash_profile
~/.profile`
etc pp.
You can precede the sourcing with a echo Hello from FILE where you replace FILE with the name of the file. That shows you the difference between shells starting from login (eg via gdm et al), via ssh connection, via new xterm etc terminals and so on.
You can force the system to read your .bashrc file by using the source command
source ~/.bashrc
Lots of inelegant and ugly ways to apply this

Resources