Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
The program that I am trying to run takes the form program_name --arg=/some/path/goes/here, but zsh cannot perform tab completion on that path when it is in the argument flag. I end up having to type progra<TAB> /so<TAB>/pa<TAB>... to complete the path and then go back to add the --arg= part of the command. Is there a more efficient way to go about doing this?
It's likely that zsh is still trying to do file completion in your situation, it's just considering the --arg= to be the initial part of the file name causing it to not find any matches. Since there aren't any universal rules for how commands will interpret their arguments the safest option is for the shell to not make any assumptions about those arguments.
Many commands which use that type of syntax will work the same if you use a space rather than the = sign, such as program_name --arg /some/path/goes/here. Since that would be a separate argument the shell should be able to do file completion without issues.
Depending on how you have zsh configured, it may also work to use setopt MAGIC_EQUAL_SUBST. I normally have that option set and get the behavior that you are looking for, but get the behavior that you currently experience if I unset that option. But, if I use zsh -f to skip loading my configuration just enabling that option isn't sufficient so there is apparently something else in my config that was necessary, possibly just the enabling of the completion system which you would likely have done already. There could be cases where this would result in undesirable behavior, but I haven't run into any in the many years that I've been using zsh with that option set.
A more complicated option would be to write a completion function for that command which tells zsh that that option takes a file name as the argument.
I am new in uniVerse and I have to write a uniVerse program which will check permissions of folders,subfolders and files. for example we have a folder called A and subfolder A1 and files in A1. now have to check if their permissions are set correctly.
lets say files on subfolder A1 are supposed to be rwxrwxr-x (775) but they are rwxrwxrwx(777). then based on this I need to report to say files on folder A1 are not set correctly.
well so far a little push/ideas/references/code snapshots etc would really help.
Thanks a mill in advance for help.
I'm more of a UniData person but in UniVerse Basic it looks like you could leverage the STATUS command which returns a dynamic array that contains the UNIX permissions in numeric form (e.g. 777).
More information available in the UniVerse Basic reference manual here: http://www.rocketsoftware.com/u2/products/universe/resources/technical-manuals/universe-11.1.11-documentation/basicref-v11r1.pdf
One of the best resources for UniVerse and RetrieVe questions is this site: http://www.mannyneira.com/universe/
If your system allows it, you should look into trying to write a script that executes via Shell. You can write UniVerse scripts that duck in and out of Shell. According to the UniVerse and Linux page on that site, you should be able to access it via the SH command.
When writing a Shell program to interact with UniVerse, you're typically going to want to use uvsh to output the data and then pipe it to something else (such as col) to manipulate it. If you pass a string to the uvsh command, it will execute it - so you can pass it commands to read file data (such as from voc pointers).
Keep in mind that every time you run the SH or uvsh command, you're nesting another shell within your current one, not switching between them.
However, it sounds like the file permission information you're interested in could be handled purely on the Shell side of things...
I must embedd the shell of an interpreter language (most likely it will be python) inside my application. So i need a console widget in my GUI toolkit. I want to write this from ground up myself.
I know that i must start the process with pipes redirecting the standard input/output/error to my console widget. I have to set the environment variable TERM=vt100 and send a SIGWINCH signal whenever i resize my terminal.
For the output of the program i have to check the octet stream for vt100 control characters as explained here VT100 commands.
This sounds to be easy and a nice weekend hack.
But what do i do about the input? Who is responsible for echoing the characters and the line mode editing?
Do i miss something else which is serious?
To control the input in console, you have set it to canonical mode. Please check this like link, it may help you:
Canonical vs. non-canonical terminal input
Do you know any resources that teach to good habits of working in UNIX command line?
EDIT: I don't mean general books about shell or man pages. I mean the things that you can only see watching professionals working with command line. For example when changing frequently between two directories they use "pushd" command, when repeating a command they use "history". I can read about these commands but I want to make it a habit to use them effectively.
I am speaking out of my own experience so it may not apply to you;
The best way to be efficient is actually using it on a daily basis, instead of using graphical tools even if they make look things easy. You will then become aware of most common tasks you care about, and instead of trying to grok it at once, you get a fairly good starting point to start learning. Man pages are the first thing to look at, but there will be non-obvious tricks which you need to search anyway. Knowing what you exactly want, infinitely increases probability of finding it.
For example, you can find how to search all mp3 files easier in man page of "find" than how to deal with files in general (where to start?).
Some common bash command line actions, not in order:
Command line editing: you'll want to be good with emacs or vi and apply that to editing your commands.
Completion: use TAB to expand file names and paths.
note: There is a huge set of file, command, and history completion functions, and it is configurable. Big topic.
"cd -" : go back to the last directory you were in
~ = home directory (or ~user for users home dir)
"ESC ." : expands to the final arg from the previous command
"!string" : execute the last command starting with string
learn find, grep, sed, piping "|" and redirection ">". You'll often combine these to do useful things.
Loops from the shell prompt, e.g. "for" loop - to do repetitive actions
Learn your regular expressions! Often used for matching files.
example: ls x[0-5]*.{zip,tar} = list files starting with x, followed by a number 0 through 5, followed by any string ending in .zip or .tar
If possible ask others for their favorite tricks, read the manual, and practice.
For the more advanced stuff This seems to be fairly comprehensive
this is a great resource: "Rute User's Tutorial and Exposition" (http://rute.2038bug.com/index.html.gz)
stackoverflow.com esp. the bash tag ;-)
(and of course the bash man page)
If you want things that you can "only see watching professionals working with command line," then you've answered your own question: Watch professionals working with the command line. I don't personally find that very useful unless the other person is doing the same thing multiple times; it's hard to pick something up after just one session because it's hard to watch the screen and the keyboard at the same time.
I think the key is to not try to become an expert right away. Just use the command line frequently, and be aware that you might not be using it as well as you could, but don't let that discourage you from using it anyway.
Browse through the man page of your shell, and through lists of tips, not with the goal of memorizing everything in them, but just to pick out a couple of things to try out. Skim through until something catches your eye and makes you think, "Gee, that sounds useful." Then try it out. Not everything is going to be useful immediately; you might have to wait a while before you encounter a situation where you can try something out. Maybe you could write down some things on Post-It notes by your desk to remind you that certain feats are possible, so when you encounter a situation where a more obscure feature could be handy, you'll be more likely to remember to try it.
Frankly, it's impossible to learn this stuff in a vacuum. You need to have problems to solve.
While it certainly helps to have familiarity with the tools available (of which there are a myriad), "learning" it requires applying it. And applying it requires "real" problems to solve.
For example, the skillset of a System Admin may be different from someone who works with databases because their roles are different.
I use them for data processing, using mostly one off files. /tmp/x.sh and /tmp/x.x are worn bare in the directory folder.
My hammers tend to lean towards: ls, find, sort, sed, vi, awk, grep, and comm. Combined with simple shell scripting like: for i in cat /tmp/list; do .. done
But I do a lot of ETL work, and very few script files, which is why my shell scripting skills are so weak.
I do rely on one script, however:
#!/bin/sh
# latest -- show latest files
ls -lt $# | head
As 95% of the time the files I'm working on are in the top 10 latest files. And "latest *.txt" works a peach.
So, bottom line, you need problems to solve. You need to learn the 'man' command, man -k is nice to find things. You also need to leverage the "See Also" at the bottom of most man pages. That's a treasure trove of "I didn't know you could do that".
Then, just start solving problems. Start figuring out "what would be nice to have" and then see if it exists (it very well may). If not, awk, perl, or python can make those "nice to haves" out of thin air.
Join a LUG. That is where I learned most things early on. Ask the organizers to do a "Bash Tips And Tricks Night".
Deft shell users love to show off.
apropos is a really good tool for this sort of thing. Whenever you find yourself unsure of the best way to do something, or wishing you weren't repeating yourself, just use apropos with a keyword or two to find other commands that can help. In distros like debian, you can also install web-based help tools that search all of the manuals available on the system: texinfo, man pages, html, and pdf etc.
Aside from that, yep, read your shell's manual right through at least once --- preferably, go back to repeatedly it as you learn more, reach limits and want to be more efficient.
The join a LUG idea is also good; you'll definitely learn from others' demos.