Shell Programming and Scripting

Hello,
What I am trying to achieve is the following:
As long as find . process is up and running, I want to show a message to the user and that is why I use

Code:

| yad --image="$MD5SUM_ICONS/binary.png" --progress --pulsate --progress-text="" --center --title="Getting things ready..." --text="Reading files..." --auto-kill --auto-close --no-buttons --no-escape --fixed

This is a yad's window running waiting for find . process to terminate yad.png - Google Drive

I use $tot_files_found to store the result coming from find . and to break from the while loop

That's all. I added wait ${!} to prevent multiple instances of find to be executed.

I am sure there are much better ways to do the same, but I am new in bash

Right now, everything seems to work but I would like to find a better way to accomplish what I want to do.

Code:

tot_files_found="$(echo $RANDOM)_find.$CURRENT_USER.$(echo $RANDOM)$(echo $RANDOM)" 
while true; do
    if [ -f "$tot_files_found" ]; then      # File exists
        if [ -s "$tot_files_found" ]; then  # File exists and not empty; (find . has written the file; operation ended)
            break
        fi     
    else
        # recursively gets the total number of files     
        find . -type f | wc -l > $tot_files_found & 
        wait ${!}
    fi
done | yad --image="$MD5SUM_ICONS/binary.png" --progress --pulsate --progress-text="" --center --title="Getting things ready..." --text="Reading files..." --auto-kill --auto-close --no-buttons --no-escape --fixed

The entire purpose of running a job asynchronously is to allow you to run other jobs at the same time. If you don't want to run any other jobs at the same time while your find command is running; don't run it asynchronously.

The two commands:

Code:

        find . -type f | wc -l > $tot_files_found & 
        wait ${!}

produce exactly the same output that the single command:

Code:

        find . -type f | wc -l > $tot_files_found

does, but takes fewer keystrokes and makes less busywork for the shell. The first two commands force the shell to create a subshell to run find asynchronously; the last command is run in the current shell execution environment without the need to create a subshell environment. The first two commands slow down your system for you and other users on your system.

Note also that every time this script runs, it creates a new temporary file and (from what you have shown us) never uses anything written into it and never removes it. And the name you are using for that temporary file (with three random numbers included in the name and with two of those random numbers adjacent to each other with no separator) increases the chance that two different invocations of your script will accidentally come up with the same name. If that happens, find will never be run for this invocation of your script.

And, there is no need to create three subshells to include those three random numbers in the name. The command:

Code:

tot_files_found=${RANDOM}_find.$CURRENT_USER.$RANDOM$RANDOM

produces exactly the same temporary filename as your current code does but avoids creating three unneeded subshells to set the name.

A more common way to do this (since there can never be two shells running with the same process ID) is to use:

Code:

tot_files_found=find.$CURRENT_USER.$$

to lessen the chance of a collision with your various multiple adjacent uses of $RANDOM. Of course, we might also comment that as far as we can tell from what you have shown us, $CURRENT_USER will expand to an empty string because it has never been set to anything else. And, since we have no idea how, or if, CURRENT_USER has been set, any expansion of tot_files_found when field splitting might occur should be included in a double-quoted string.

From everything that you have said about what you are trying to do, I do not understand why you have a loop at all? The following would seem to be a better fit for your stated goals (which I still do not understand):

Code:

tot_files_found=find.$CURRENT_USER.$$ 

# recursively gets the total number of files     
find . -type f | wc -l > "$tot_files_found" |
    yad --image="$MD5SUM_ICONS/binary.png" --progress --pulsate \
        --progress-text="" --center --title="Getting things ready..." \
        --text="Reading files..." --auto-kill --auto-close --no-buttons \
        --no-escape --fixed

But, as has been said before, having yad as the second process in a pipeline when the first process in that pipeline will NEVER write anything into that pipe is not a "normal" way to do things. Whatever output yad produces has nothing to do with whether or not find is making any progress; all it can tell us is when find has terminated. And that could be done more simply with:

Code:

tot_files_found=find.$CURRENT_USER.$$ 

# recursively gets the total number of files     
echo 'find is running'
find . -type f | wc -l > "$tot_files_found"
echo 'find is done'

We should probably also include a trap to remove the temporary file created by this script, but I haven't yet figured out if there might be some reason why you would want to actually know how many files were found instead of just wasting time figuring out how many there are and then exiting without ever looking at the results.

To show the yad picture while find is running, did you consider

Code:

yad ... &
find ...
kill %1 (yad's jobspec, hopefully)

To expand on what my colleagues RudiC and Don Cragun has already said:

I might not be (see above) the biggest expert on all things subshell but i know a thing or two about programming. Make no mistake, writing a shell script of 5 lines is essentially a programming task and it is never too early to start on healthy habits.

Programming is mostly about organizing your thoughts and the best way to organize them is to compartmentalize big problems into several smaller problems again and again until there are no problems any more. It is like moving a big heap: you take a shovel and dig one small shovel full after the other until there is no heap any more. If you try to move the whole pile you are likely to fail but with a single shovel full it is easy to succeed. One shovel - success, and another one - success again and before you notice you have the pile moved.

So, let us start with - as exactly as possible - clarify your goals: you want to get a count of (a certain type of) files within a certain subtree. Yes? (I don't mind if you respond "NO!" here, because this is what this stage is about - clarifying your goals. If i haven't understood them correctly just say so.)

You also want - because the operation might take some time - display a window telling the user to wait for completion which you want to update to tell when the counting is finished (probably, but that is my assumption, along with presenting the result). Yes?

So, first for the counting - note that we set aside everything else here! Again, shovel for shovel and we concern ourselves here with only this shovel, not the pile and not another shovel. We can use find for this but we can do that in a single instance because find can traverse the filesystem (or select parts of it) on its own. To start several instances of find and then compile their results is simply not necessary. In addition to what RudiC and Don Cragun already said you find a more thorough introduction to find here. See how far that gets you and ask if you still have questions.

There is another question to this: how is the result of this operation propagated to whereever you will need it. I will postpone that for the moment because the rest of the operation is not clear yet.

Second is the business with the user notification. I told you above that the basic logic of this is to:

- present a user the initial window with a "please wait..."-message
- run the find-operation
- replace the "please wait...."-message with something else (i.e. a "done" or "result is:..."-message)

This is basically the same as what RudiC (and myself) earlier have already suggested. For this you do not need any pipes, background processes or anything else of that sort as Don Cragun has already explained.

So, if you want help for the further commencement of this, you are welcome to more clearly describe your goals and we can take it from there.

I hope this helps.

bakunin

In the end, thanks to you guys, I did the following:

Code:

tot_files_found=0
yad --image="$MD5SUM_ICONS/binary.png" --progress --pulsate --progress-text="" --center --title="Getting things ready..." --text="Reading files..." --auto-kill --auto-close --no-buttons --no-escape --width=300 --height=$HEIGHT &
tot_files_found=$(find . -type f -perm -a=r | wc -l)
kill %1

and since I am not using a sub-shell any-longer, I am able to store the value returned by find into a regular variable instead of a file
On top of that, I changed all the $(echo $RANDOM) with .$CURRENT_USER.$$ in my other scripts too.

One last thing though... Is possible to kill/terminate the find process as soon as I close the yad window?

Bye and thank you so much for all your help and detailed explanations.

Here are two tips: first, if you operate with variables inside larger expressions like .$CURRENT_USER.$$ it is a good idea to use the long form of notation: .${CURRENT_USER}. The difference is that the curly braces make sure where the variables name ends and the rest of the string begins so that this rest of the string is not mistaken as a part of the variables name. For example: you want to add a slash to a variable so $var/ is fine, but add an underscore instead and $var_ would be interpreted as a variable named "var_". ${var}_ will always work, though.

Another tip is: clean up behind you. If you create a temporary file make sure that it is removed when the program creating it exits. You can do that with "traps", which is a theme for another thread but you might want to read up the shells documentation for it.

Yes - but that would be really advanced stuff. You would need to go back to sending the [icode]find/icode] into background, then the yad-window in another background and check in the main program if either of these subprocesses are finished, then kill the other. The logic is tricky and i suggest to put that on the backburner until you have some experience with shell programming. Get some shell-programming done and you will be able to do it in short time.

I hope this helps.

bakunin