macOS OS X Terminal File Names Order and Reference

[jamesadrian]

Adrian,

The below statement is giving you access to all and each one of the files in the input directory ($1), except directories. Not only the first file as you have been thinking.
--------------------------------------------------------------
for inputFile in `ls -l $1 | grep "^-" | awk '{print $(NF)}'`
do
---------------------------------------------------------------


Your C program redirects the standard input and output through < and > symbols. So inside your C program you don't need to open and close files. This is the reason I say the program doesn't need to know anything about filenames.
---------------------------------------------------------------------------
if yourCProgram < $1/$inputFile > $2/$inputFile
---------------------------------------------------------------------------


If the execution of your C program is okay the file in progress is removed.
----------------------------------------------------------------------------------
then rm $1/$inputFile
----------------------------------------------------------------------------------



Putting everything together

for inputFile in `ls -l $1 | grep "^-" | awk '{print $(NF)}'`
do
if yourCProgram < $1/$inputFile > $2/$inputFile
then rm $1/$inputFile
fi
done

With a lot of help for all of you and some others, I have been working on a script that takes the other approach. It does not seem to work yet, but here it is:

#!/bin/bash
# I discovered this path by entering this command:  which bash
# setup test dirs and files
d1="dir1"
d2="dir2"
cd /tmp
rm -rf $d1
rm -rf $d2
mkdir $d1
touch $d1/f1
touch $d1/f2
mkdir $d2

# define function
function func1
{
	fname=$1
	echo "in func1, parm fname=$fname"
}

# show current dir state
echo
echo "before looping through files"
echo "------------------------"
echo "$d1 contents"
ls $d1
echo "$d2 contents"
ls $d2

echo
echo "looping through files in $d1"
echo "------------------------"
# loop through files in d1
for f in $(ls -1 $d1)
do
	# call function
	func1 $f
	
	# move file to d2
	mv $d1/$f $d2/
        break
done


# confirm results of moved files
echo
echo "after looping through files"
echo "------------------------"
echo "$d1 contents"
ls $d1
echo "$d2 contents"
ls $d2
echo "------------------------"
echo "done"

James Adrian
jim@futurebeacon.com

 

[chown33]

With a lot of help for all of you and some others, I have been working on a script that takes the other approach. It does not seem to work yet, but here it is:

Please describe what the script is expected to do. We could guess, but it's much clearer if you tell us what it should do.

Rules of Thumb:
1. Describe what you expected to happen.
2. Describe what actually happened.

# loop through files in d1
for f in $(ls -1 $d1)
do
	# call function
	func1 $f
	
	# move file to d2
	mv $d1/$f $d2/
        [COLOR="Red"]break[/COLOR]
done

In this loop, what do you intend the red-hilited break to do? Here's what the bash reference says it does:

Exit from within a for, while, until, or select loop.
​

If that's what you intend, then you should explain what the overall intent of the loop is. If that's not what you intend, then you should ask yourself why it's there at all.

 

[jamesadrian]

Please describe what the script is expected to do. We could guess, but it's much clearer if you tell us what it should do.

Rules of Thumb:
1. Describe what you expected to happen.
2. Describe what actually happened.

# loop through files in d1
for f in $(ls -1 $d1)
do
	# call function
	func1 $f
	
	# move file to d2
	mv $d1/$f $d2/
        [COLOR="Red"]break[/COLOR]
done

In this loop, what do you intend the red-hilited break to do? Here's what the bash reference says it does:

Exit from within a for, while, until, or select loop.
​

If that's what you intend, then you should explain what the overall intent of the loop is. If that's not what you intend, then you should ask yourself why it's there at all.

The script I call fileloop above is supposed to move the files in a directory to another directory. I place both of these directories in my home directory and invoked the the program with this command: ./fileloop

I had previously entered chmod 777 fileloop.

The program does not move any files.

Thank you for your help.

I had expected the break command to stop the program and display something until a key press starts it up again. I guess that is wrong. I tried it without the break command and got the same result. No files were move.

James Adrian
jim@futurebeacon.com
James Adrian
jim@futurebeacon.com

 

[chown33]

The script I call fileloop above is supposed to move the files in a directory to another directory. I place both of these directories in my home directory and invoked the the program with this command: ./fileloop

I had previously entered chmod 777 fileloop.

The program does not move any files.

Your shell script contains this line:

cd /tmp

What do you think this does?

It's very important that you understand everything you put into your script. If you don't understand what you're telling the script to do, you really shouldn't be surprised if it does something you don't understand. It can't read your mind. It does exactly what you tell it to do, even if you don't understand what you told it.


When I run your shell script exactly as posted (i.e. with the 'break' in the loop), it produces this output:

before looping through files
------------------------
dir1 contents
f1      f2
dir2 contents

looping through files in dir1
------------------------
in func1, parm fname=f1

after looping through files
------------------------
dir1 contents
f2
dir2 contents
f1
------------------------
done

Looking at the "after looping through files" output, it clearly shows dir1 containing f2, and dir2 containing f1. If you compare that to the "before looping", it plainly has moved one file: f1.

But exactly where are the directories dir1 and dir2 located? The answer requires understanding the line I pointed out above.

When I look in the correct location, the directories dir1 and dir2 exist, and contain exactly the files that the output says they do. So the problem isn't that the script isn't working. The problem seems to be that you don't understand what you told the script to do.

I had expected the break command to stop the program and display something until a key press starts it up again. I guess that is wrong.

Yes, it is wrong. The question I have to ask is this: Why did you expect the program to stop and display something until a key is pressed? That isn't even remotely close to what the description for 'break' says.

 

[jamesadrian]

Your shell script contains this line:

cd /tmp

What do you think this does?

It's very important that you understand everything you put into your script. If you don't understand what you're telling the script to do, you really shouldn't be surprised if it does something you don't understand. It can't read your mind. It does exactly what you tell it to do, even if you don't understand what you told it.


When I run your shell script exactly as posted (i.e. with the 'break' in the loop), it produces this output:

before looping through files
------------------------
dir1 contents
f1      f2
dir2 contents

looping through files in dir1
------------------------
in func1, parm fname=f1

after looping through files
------------------------
dir1 contents
f2
dir2 contents
f1
------------------------
done

Looking at the "after looping through files" output, it clearly shows dir1 containing f2, and dir2 containing f1. If you compare that to the "before looping", it plainly has moved one file: f1.

But exactly where are the directories dir1 and dir2 located? The answer requires understanding the line I pointed out above.

When I look in the correct location, the directories dir1 and dir2 exist, and contain exactly the files that the output says they do. So the problem isn't that the script isn't working. The problem seems to be that you don't understand what you told the script to do.



Yes, it is wrong. The question I have to ask is this: Why did you expect the program to stop and display something until a key is pressed? That isn't even remotely close to what the description for 'break' says.

If you make the price of failure high enough, nobody will try.

I will now try to hire a consultant.

James Adrian