Some doubts with Shell Scripting. - linux

I have a couple of requirements to be satisfied using shell scripts. Since I am trio in this area, i would certainly need your help.
1) I have a script which invokes a env-function which will ask for a user input to proceed with the execution. I want my script to supply the answer to this. How can i implement this.
Doing a bit of googling pointed me to an "expect" command, which is unfortunately not installed in my system. Is there any other way to achieve this task?
2) I have another requirement like, the script should find the total number of CPUs in my pc and should append the "-j(2*no. of CPU)" to my make command.
Could somebody please shed some light into how this can be done.
Thanks,
Sen

Since the first part has been answered, for the 2nd part you can try something like
#!/bin/sh
cpu=`cat /proc/cpuinfo | grep -e '^processor' | wc -l`
jobs=$(echo "$cpu * 2" | bc)
make -j$jobs

I have another requirement like, the script should find the total
number of CPUs in my pc
You can read the output of
/proc/cpuinfo
or even better:
You can narrow down output with the following command, to display number of processors in the system:
grep processor /proc/cpuinfo

you can simply redirect an input to that program. An example with checkinstall:
checkinstall < /path/to/file/with/answers

Related

Creat File with Process Names with filter

For a UNIX class we are supposed to create a file with the name deamons that contains all the processes whose names end with d.
My approach was to use something like:
ps | find PID *d
or
find *d > ps
but none of these approaches is anywhere close to achieving the results I want.
We have used ls, ps, find, grep and some other basic UNIX commands so far. The terminal runs in CentOS 5 and we don't have rights to install any packages.
Well ... you're using the wrong tool, find is for finding files. You want to use grep. A bare ps probably also isn't what you want.
ps -e | grep 'd$' > daemons
I highly recommend that you familiarise yourself with the tools at your disposal before stringing them together.
Btw, what were the outputs/results of your own invocations? ;)
That's a good learning exercise, trying to understand what you actually did.

Linux piping behaviour

Ok this is merely to satisfy my curiosity and anyone else that might have a similar question. Please bear with the ignorance and lengthy question as its partially a case of "i dont know what i dont know".
Section 1
Assume a fileToFollow.txt that has some arbitrary content.
row1
row2
row3
Executing tail fileToFollow.txt | cat yields the contents of the file as expected.
Executing tail -f fileToFollow.txt | cat will keep on outputing anything that is written into fileToFollow.txt
I imagined piping as getting the output of one program and feeding it into the input of another ( so for example if cat was a C program it would be able to access that input through the main() arguments ).
Question 1: Is that whats going on here, is cat just called everytime tail has an output?
Section 2
I decided to throw grep into the mix setting up the following:
tail -f fileToFollow.txt | grep "whatever" | cat
Clearly cat is not needed here as grep itself does output to the terminal anyway. But given the idea that piping is output from one program to input in another, i was assuming it would. However, in this case no output is displayed in the terminal.
The following of course works fine:
tail -f fileToFollow.txt | grep "whatever"
I have a hunch i am little bit confused as to how piping might actually work and why the cases i presented aren't behaving as i would expect them to.
Any kind of enlightenment is welcome. Thanks a bunch for taking the time.
Answer to question 1: No, cat is running as a process all the time but it's blocked reading stdin when there is nothing available. When the process before it in the pipeline (tail) writes new bytes to the pipe, the read call will return and cat is able to process the new data. After that it will read again and block until new data is available.
When you pipe into a program, the stdout of the source will usually switch into buffered mode (see man setvbuf()), which means that a certain amount of data (2KiB or 4KiB or so) must be generated before it will be given to write(2).
Giving it out to tty uses line buffered mode so that buffers are flushed after \n.
There exists a stdbuf tool to modify this behavior.

Documentation for uinput

I am trying very hard to find the documentation for the uinput but the only thing I have found was the linux/uinput.h. I have also found some tutorials on the internet but no documentation at all!
For example I would like to know what UI_SET_MSCBIT does but I can't find anything about it.
How does people know how to use uinput?
Well, it takes some investigation effort for such subtle things. From
drivers/input/misc/uinput.c and include/uapi/linux/uinput.h files you can see bits for UI_SET_* definitions, like this:
MSC
REL
LED
etc.
Run next command in kernel sources directory:
$ git grep --all-match -e 'MSC' -e 'REL' -e 'LED' -- Documentation/*
or use regular grep, if your kernel doesn't have .git directory:
$ grep -rl MSC Documentation/* | xargs grep -l REL | xargs grep -l LED
You'll get this file: Documentation/input/event-codes.txt, from which you can see:
EV_MSC: Used to describe miscellaneous input data that do not fit into other types.
EV_MSC events are used for input and output events that do not fall under other categories.
A few EV_MSC codes have special meaning:
MSC_TIMESTAMP: Used to report the number of microseconds since the last reset. This event should be coded as an uint32 value, which is allowed to wrap around with no special consequence. It is assumed that the time difference between two consecutive events is reliable on a reasonable time scale (hours). A reset to zero can happen, in which case the time since the last event is unknown. If the device does not provide this information, the driver must not provide it to user space.
I'm afraid this is the best you can find out there for UI_SET_MSCBIT out there.

How to get output of top command

I'm wondering how to get the output of the 'top' command. I'm looking to obtain the number of currently running processes.
I tried putting it to a text file and got garbage. I'm unsure on how to approach this. My assignment is to determine the number of processes considered by the short-term scheduler for process allocation (processes currently ready to run) at any given time.
Use top in batch mode:
top -bn1 > output.txt
See also this previous answer.
Easier than parsing top you could count the lines in the process list:
ps -ef | wc -l

Is it possible to display the progress of a sort in linux?

My job involves a lot of sorting fields from very large files. I usually do this with the sort command in bash. Unfortunately, when I start a sort I am never really sure how long it is going to take. Should I wait a second for the results to appear, or should I start working on something else while it runs?
Is there any possible way to get an idea of how far along a sort has progressed or how fast it is working?
$ cut -d , -f 3 VERY_BIG_FILE | sort -du > output
No, GNU sort does not do progress reporting.
However, if are you using sort just to remove duplicates, and you don't actually care about the ordering, then there's a more scalable way of doing that:
awk '! a[$0]++'
This writes out the first occurrence of a line as soon as it's been seen, which can give you an idea of the progress.
You might want to give pv a try, it should give you a pretty good idea of what is going on in your pipe in terms of throughput.
Example (untested) injecting pv before and after the sort command to get an idea of the throughput:
$ cut -d , -f 3 VERY_BIG_FILE | pv -cN cut | sort -du | pv -cN sort > output
EDIT: I missed the -u in your sort command, so calculating lines first to be able to get a percentage output is void. Removed that part from my answer.
You can execute your "sort" in background
you will get prompt and you can do other jobs
$sort ...... & # (& means run in background )

Resources