Problems with “while” bash










3















I need to control files in a folder... The script has to wait the file until it exists...



These files have the name... The format is file_d01_YYYY-MM-DD_HH:00:00. For example:



file_d01_2018-11-12_00:00:00
file_d01_2018-11-12_01:00:00


And so on, for 7 days ahead.



!/bin/bash


ZZ=`date +%k`
date=$(date +%Y%m%d)
if [[ $ZZ -ge 2 ]] && [[ $ZZ -lt 14 ]] ; then #03:45 UTC
ZZ=00
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
elif [[ $ZZ -ge 14 ]] && [[ $ZZ -lt 23 ]] ; then #15:45 UTC
ZZ=12
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
fi


rundir=/home/$PARAM/wrfv3
dir=/home/$PARAM

data=$(date +%Y-%m-%d)
data1=$(date -d "1 day" +%Y-%m-%d)
data2=$(date -d "2 day" +%Y-%m-%d)
data3=$(date -d "3 day" +%Y-%m-%d)
data4=$(date -d "4 day" +%Y-%m-%d)
data5=$(date -d "5 day" +%Y-%m-%d)
data6=$(date -d "6 day" +%Y-%m-%d)




days=( "$data" "$data1" "$data2" "$data3" "$data4" "$data5" "$data6" ) #array of days
values=( 00..23 ) #array of 24 hours
echo $#values[@]

# Here, using to loops, I check if files exist...for every day and hour
for day in "$days[@]"; do
for value in "$values[@]"; do
echo file_d01_$day_$value:00:00

while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ] # while file doesn't exist...wait...and repeat checking till it exists...
do
echo "waiting for the file"
sleep 10
done
echo "file exists"
sleep 5

done
done


I receive always "waiting for the file"...and they exist... where is the problema in the code?










share|improve this question



















  • 3





    Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

    – Eric Renouf
    Nov 12 '18 at 21:48






  • 1





    A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

    – Charles Duffy
    Nov 13 '18 at 20:01
















3















I need to control files in a folder... The script has to wait the file until it exists...



These files have the name... The format is file_d01_YYYY-MM-DD_HH:00:00. For example:



file_d01_2018-11-12_00:00:00
file_d01_2018-11-12_01:00:00


And so on, for 7 days ahead.



!/bin/bash


ZZ=`date +%k`
date=$(date +%Y%m%d)
if [[ $ZZ -ge 2 ]] && [[ $ZZ -lt 14 ]] ; then #03:45 UTC
ZZ=00
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
elif [[ $ZZ -ge 14 ]] && [[ $ZZ -lt 23 ]] ; then #15:45 UTC
ZZ=12
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
fi


rundir=/home/$PARAM/wrfv3
dir=/home/$PARAM

data=$(date +%Y-%m-%d)
data1=$(date -d "1 day" +%Y-%m-%d)
data2=$(date -d "2 day" +%Y-%m-%d)
data3=$(date -d "3 day" +%Y-%m-%d)
data4=$(date -d "4 day" +%Y-%m-%d)
data5=$(date -d "5 day" +%Y-%m-%d)
data6=$(date -d "6 day" +%Y-%m-%d)




days=( "$data" "$data1" "$data2" "$data3" "$data4" "$data5" "$data6" ) #array of days
values=( 00..23 ) #array of 24 hours
echo $#values[@]

# Here, using to loops, I check if files exist...for every day and hour
for day in "$days[@]"; do
for value in "$values[@]"; do
echo file_d01_$day_$value:00:00

while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ] # while file doesn't exist...wait...and repeat checking till it exists...
do
echo "waiting for the file"
sleep 10
done
echo "file exists"
sleep 5

done
done


I receive always "waiting for the file"...and they exist... where is the problema in the code?










share|improve this question



















  • 3





    Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

    – Eric Renouf
    Nov 12 '18 at 21:48






  • 1





    A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

    – Charles Duffy
    Nov 13 '18 at 20:01














3












3








3








I need to control files in a folder... The script has to wait the file until it exists...



These files have the name... The format is file_d01_YYYY-MM-DD_HH:00:00. For example:



file_d01_2018-11-12_00:00:00
file_d01_2018-11-12_01:00:00


And so on, for 7 days ahead.



!/bin/bash


ZZ=`date +%k`
date=$(date +%Y%m%d)
if [[ $ZZ -ge 2 ]] && [[ $ZZ -lt 14 ]] ; then #03:45 UTC
ZZ=00
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
elif [[ $ZZ -ge 14 ]] && [[ $ZZ -lt 23 ]] ; then #15:45 UTC
ZZ=12
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
fi


rundir=/home/$PARAM/wrfv3
dir=/home/$PARAM

data=$(date +%Y-%m-%d)
data1=$(date -d "1 day" +%Y-%m-%d)
data2=$(date -d "2 day" +%Y-%m-%d)
data3=$(date -d "3 day" +%Y-%m-%d)
data4=$(date -d "4 day" +%Y-%m-%d)
data5=$(date -d "5 day" +%Y-%m-%d)
data6=$(date -d "6 day" +%Y-%m-%d)




days=( "$data" "$data1" "$data2" "$data3" "$data4" "$data5" "$data6" ) #array of days
values=( 00..23 ) #array of 24 hours
echo $#values[@]

# Here, using to loops, I check if files exist...for every day and hour
for day in "$days[@]"; do
for value in "$values[@]"; do
echo file_d01_$day_$value:00:00

while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ] # while file doesn't exist...wait...and repeat checking till it exists...
do
echo "waiting for the file"
sleep 10
done
echo "file exists"
sleep 5

done
done


I receive always "waiting for the file"...and they exist... where is the problema in the code?










share|improve this question
















I need to control files in a folder... The script has to wait the file until it exists...



These files have the name... The format is file_d01_YYYY-MM-DD_HH:00:00. For example:



file_d01_2018-11-12_00:00:00
file_d01_2018-11-12_01:00:00


And so on, for 7 days ahead.



!/bin/bash


ZZ=`date +%k`
date=$(date +%Y%m%d)
if [[ $ZZ -ge 2 ]] && [[ $ZZ -lt 14 ]] ; then #03:45 UTC
ZZ=00
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
elif [[ $ZZ -ge 14 ]] && [[ $ZZ -lt 23 ]] ; then #15:45 UTC
ZZ=12
PARAM=`date +%Y%m%d`$ZZ
PARAM2=`date +%Y-%m-%d`
fi


rundir=/home/$PARAM/wrfv3
dir=/home/$PARAM

data=$(date +%Y-%m-%d)
data1=$(date -d "1 day" +%Y-%m-%d)
data2=$(date -d "2 day" +%Y-%m-%d)
data3=$(date -d "3 day" +%Y-%m-%d)
data4=$(date -d "4 day" +%Y-%m-%d)
data5=$(date -d "5 day" +%Y-%m-%d)
data6=$(date -d "6 day" +%Y-%m-%d)




days=( "$data" "$data1" "$data2" "$data3" "$data4" "$data5" "$data6" ) #array of days
values=( 00..23 ) #array of 24 hours
echo $#values[@]

# Here, using to loops, I check if files exist...for every day and hour
for day in "$days[@]"; do
for value in "$values[@]"; do
echo file_d01_$day_$value:00:00

while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ] # while file doesn't exist...wait...and repeat checking till it exists...
do
echo "waiting for the file"
sleep 10
done
echo "file exists"
sleep 5

done
done


I receive always "waiting for the file"...and they exist... where is the problema in the code?







bash while-loop






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 12 '18 at 23:56









Amessihel

2,3891724




2,3891724










asked Nov 12 '18 at 21:25









Enric Agud PiqueEnric Agud Pique

4523823




4523823







  • 3





    Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

    – Eric Renouf
    Nov 12 '18 at 21:48






  • 1





    A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

    – Charles Duffy
    Nov 13 '18 at 20:01













  • 3





    Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

    – Eric Renouf
    Nov 12 '18 at 21:48






  • 1





    A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

    – Charles Duffy
    Nov 13 '18 at 20:01








3




3





Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

– Eric Renouf
Nov 12 '18 at 21:48





Are you really sure the file exists? Perhaps use set -x to see the expanded version of the path at that point. (Also, consider using shellcheck.net to find a lot of gotchas.)

– Eric Renouf
Nov 12 '18 at 21:48




1




1





A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

– Charles Duffy
Nov 13 '18 at 20:01






A good Stack Overflow question containing code has that code presented as a Minimal, Complete, and Verifiable example -- the shortest possible code that anyone else can run themselves to see the same problem, with everything unrelated to that problem removed.

– Charles Duffy
Nov 13 '18 at 20:01













2 Answers
2






active

oldest

votes


















2














You should add the double quotes "" to protect the path. It's a good practice. Also bash expansion escapes the : character, so maybe it is an issue in your context (not in the one i did the test).



while [ ! -e "$rundir/file_d01_2018-11-15_20:00:00" ]


I would suggest to follow those steps:



  1. Protect the path with double quotes "" (not simple ones, otherwise $rundir won't be expanded)

  2. Write echo "waiting for the file $rundir/file_d01_2018-11-15_20:00:00" to see what path you're testing

  3. Additionally, use -e to see any changes (-e checks for a path existence, not only a regular file one)

Note: the brackets [ ] invokes in fact test. So, man test will give you the operators you can use and their meanings. Also nowadays bash has double brackets [[ ]] as built-in operators, more powerful, which can be used instead.






share|improve this answer

























  • -f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

    – Eric Renouf
    Nov 12 '18 at 21:46











  • This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

    – Mike Holt
    Nov 12 '18 at 22:29











  • Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

    – Mike Holt
    Nov 12 '18 at 22:39











  • Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

    – Amessihel
    Nov 12 '18 at 22:46












  • Thanks you also @EricRenouf.

    – Amessihel
    Nov 12 '18 at 22:49


















0














The code in the question contains:



echo file_d01_$day_$value:00:00
while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ]


It's calculating a file name, echoing it, and then checking for a (probably different) fixed, unchanging, file name. It should check for the calculated file name. For example:



file=file_d01_$day_$value:00:00
echo "$file"
while [ ! -f "$rundir/$file" ]


To make debugging easier, it would be better to have:



filepath=$rundir/file_d01_$day_$value:00:00
echo "$filepath"
while [ ! -f "$filepath" ]


The full code in the question has many issues (starting with a broken shebang line). It's a good idea to make Bash code Shellcheck-clean.






share|improve this answer























  • Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

    – Charles Duffy
    Nov 13 '18 at 20:04











Your Answer






StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270347%2fproblems-with-while-bash%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














You should add the double quotes "" to protect the path. It's a good practice. Also bash expansion escapes the : character, so maybe it is an issue in your context (not in the one i did the test).



while [ ! -e "$rundir/file_d01_2018-11-15_20:00:00" ]


I would suggest to follow those steps:



  1. Protect the path with double quotes "" (not simple ones, otherwise $rundir won't be expanded)

  2. Write echo "waiting for the file $rundir/file_d01_2018-11-15_20:00:00" to see what path you're testing

  3. Additionally, use -e to see any changes (-e checks for a path existence, not only a regular file one)

Note: the brackets [ ] invokes in fact test. So, man test will give you the operators you can use and their meanings. Also nowadays bash has double brackets [[ ]] as built-in operators, more powerful, which can be used instead.






share|improve this answer

























  • -f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

    – Eric Renouf
    Nov 12 '18 at 21:46











  • This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

    – Mike Holt
    Nov 12 '18 at 22:29











  • Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

    – Mike Holt
    Nov 12 '18 at 22:39











  • Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

    – Amessihel
    Nov 12 '18 at 22:46












  • Thanks you also @EricRenouf.

    – Amessihel
    Nov 12 '18 at 22:49















2














You should add the double quotes "" to protect the path. It's a good practice. Also bash expansion escapes the : character, so maybe it is an issue in your context (not in the one i did the test).



while [ ! -e "$rundir/file_d01_2018-11-15_20:00:00" ]


I would suggest to follow those steps:



  1. Protect the path with double quotes "" (not simple ones, otherwise $rundir won't be expanded)

  2. Write echo "waiting for the file $rundir/file_d01_2018-11-15_20:00:00" to see what path you're testing

  3. Additionally, use -e to see any changes (-e checks for a path existence, not only a regular file one)

Note: the brackets [ ] invokes in fact test. So, man test will give you the operators you can use and their meanings. Also nowadays bash has double brackets [[ ]] as built-in operators, more powerful, which can be used instead.






share|improve this answer

























  • -f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

    – Eric Renouf
    Nov 12 '18 at 21:46











  • This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

    – Mike Holt
    Nov 12 '18 at 22:29











  • Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

    – Mike Holt
    Nov 12 '18 at 22:39











  • Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

    – Amessihel
    Nov 12 '18 at 22:46












  • Thanks you also @EricRenouf.

    – Amessihel
    Nov 12 '18 at 22:49













2












2








2







You should add the double quotes "" to protect the path. It's a good practice. Also bash expansion escapes the : character, so maybe it is an issue in your context (not in the one i did the test).



while [ ! -e "$rundir/file_d01_2018-11-15_20:00:00" ]


I would suggest to follow those steps:



  1. Protect the path with double quotes "" (not simple ones, otherwise $rundir won't be expanded)

  2. Write echo "waiting for the file $rundir/file_d01_2018-11-15_20:00:00" to see what path you're testing

  3. Additionally, use -e to see any changes (-e checks for a path existence, not only a regular file one)

Note: the brackets [ ] invokes in fact test. So, man test will give you the operators you can use and their meanings. Also nowadays bash has double brackets [[ ]] as built-in operators, more powerful, which can be used instead.






share|improve this answer















You should add the double quotes "" to protect the path. It's a good practice. Also bash expansion escapes the : character, so maybe it is an issue in your context (not in the one i did the test).



while [ ! -e "$rundir/file_d01_2018-11-15_20:00:00" ]


I would suggest to follow those steps:



  1. Protect the path with double quotes "" (not simple ones, otherwise $rundir won't be expanded)

  2. Write echo "waiting for the file $rundir/file_d01_2018-11-15_20:00:00" to see what path you're testing

  3. Additionally, use -e to see any changes (-e checks for a path existence, not only a regular file one)

Note: the brackets [ ] invokes in fact test. So, man test will give you the operators you can use and their meanings. Also nowadays bash has double brackets [[ ]] as built-in operators, more powerful, which can be used instead.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 13 '18 at 21:11

























answered Nov 12 '18 at 21:32









AmessihelAmessihel

2,3891724




2,3891724












  • -f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

    – Eric Renouf
    Nov 12 '18 at 21:46











  • This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

    – Mike Holt
    Nov 12 '18 at 22:29











  • Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

    – Mike Holt
    Nov 12 '18 at 22:39











  • Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

    – Amessihel
    Nov 12 '18 at 22:46












  • Thanks you also @EricRenouf.

    – Amessihel
    Nov 12 '18 at 22:49

















  • -f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

    – Eric Renouf
    Nov 12 '18 at 21:46











  • This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

    – Mike Holt
    Nov 12 '18 at 22:29











  • Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

    – Mike Holt
    Nov 12 '18 at 22:39











  • Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

    – Amessihel
    Nov 12 '18 at 22:46












  • Thanks you also @EricRenouf.

    – Amessihel
    Nov 12 '18 at 22:49
















-f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

– Eric Renouf
Nov 12 '18 at 21:46





-f will test if it exists and is a regular file, so a directory would not pass -f but would pass -e for example

– Eric Renouf
Nov 12 '18 at 21:46













This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

– Mike Holt
Nov 12 '18 at 22:29





This is a misleading answer. There is nothing in the question that indicates that the use of -f instead of -e might be an issue here. It sounds more like a quoting issue, and while you did mention that in your edit, the answer still reads as "you need to use -e instead of -f".

– Mike Holt
Nov 12 '18 at 22:29













Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

– Mike Holt
Nov 12 '18 at 22:39





Much better. Have an upvote. I would caution against making a habit of using -e when you are actually testing for the existence of a regular file. The more your code aligns with what you're expecting to be happening, the less chance there is that something will go haywire. For this reason, any time I am working with regular files, I use -f so that there is no doubt. In the past, I've written scripts that obliterated whole directories of important data, because of little details like that leading to unexpected consequences. Bottom line, if you mean files, your code should use -f.

– Mike Holt
Nov 12 '18 at 22:39













Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

– Amessihel
Nov 12 '18 at 22:46






Good point @MikeHolt, indeed. Thanks for the notice and your pretty cool behaviour.

– Amessihel
Nov 12 '18 at 22:46














Thanks you also @EricRenouf.

– Amessihel
Nov 12 '18 at 22:49





Thanks you also @EricRenouf.

– Amessihel
Nov 12 '18 at 22:49













0














The code in the question contains:



echo file_d01_$day_$value:00:00
while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ]


It's calculating a file name, echoing it, and then checking for a (probably different) fixed, unchanging, file name. It should check for the calculated file name. For example:



file=file_d01_$day_$value:00:00
echo "$file"
while [ ! -f "$rundir/$file" ]


To make debugging easier, it would be better to have:



filepath=$rundir/file_d01_$day_$value:00:00
echo "$filepath"
while [ ! -f "$filepath" ]


The full code in the question has many issues (starting with a broken shebang line). It's a good idea to make Bash code Shellcheck-clean.






share|improve this answer























  • Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

    – Charles Duffy
    Nov 13 '18 at 20:04
















0














The code in the question contains:



echo file_d01_$day_$value:00:00
while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ]


It's calculating a file name, echoing it, and then checking for a (probably different) fixed, unchanging, file name. It should check for the calculated file name. For example:



file=file_d01_$day_$value:00:00
echo "$file"
while [ ! -f "$rundir/$file" ]


To make debugging easier, it would be better to have:



filepath=$rundir/file_d01_$day_$value:00:00
echo "$filepath"
while [ ! -f "$filepath" ]


The full code in the question has many issues (starting with a broken shebang line). It's a good idea to make Bash code Shellcheck-clean.






share|improve this answer























  • Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

    – Charles Duffy
    Nov 13 '18 at 20:04














0












0








0







The code in the question contains:



echo file_d01_$day_$value:00:00
while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ]


It's calculating a file name, echoing it, and then checking for a (probably different) fixed, unchanging, file name. It should check for the calculated file name. For example:



file=file_d01_$day_$value:00:00
echo "$file"
while [ ! -f "$rundir/$file" ]


To make debugging easier, it would be better to have:



filepath=$rundir/file_d01_$day_$value:00:00
echo "$filepath"
while [ ! -f "$filepath" ]


The full code in the question has many issues (starting with a broken shebang line). It's a good idea to make Bash code Shellcheck-clean.






share|improve this answer













The code in the question contains:



echo file_d01_$day_$value:00:00
while [ ! -f $rundir/file_d01_2018-11-15_20:00:00 ]


It's calculating a file name, echoing it, and then checking for a (probably different) fixed, unchanging, file name. It should check for the calculated file name. For example:



file=file_d01_$day_$value:00:00
echo "$file"
while [ ! -f "$rundir/$file" ]


To make debugging easier, it would be better to have:



filepath=$rundir/file_d01_$day_$value:00:00
echo "$filepath"
while [ ! -f "$filepath" ]


The full code in the question has many issues (starting with a broken shebang line). It's a good idea to make Bash code Shellcheck-clean.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 13 '18 at 19:49









pjhpjh

1,719612




1,719612












  • Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

    – Charles Duffy
    Nov 13 '18 at 20:04


















  • Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

    – Charles Duffy
    Nov 13 '18 at 20:04

















Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

– Charles Duffy
Nov 13 '18 at 20:04






Insofar as the code has a wider array of problems than can be reasonably answered, that's a reason not to answer it but instead to vote for closure -- see the "Answer Well-Asked Questions" section in How to Answer, particularly the bullet points regarding questions which "require too much guidance for you to answer in full", and the inclusion by reference of What topics can I ask about here?, which itself references Minimal, Complete, and Verifiable example rules.

– Charles Duffy
Nov 13 '18 at 20:04


















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid


  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270347%2fproblems-with-while-bash%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Use pre created SQLite database for Android project in kotlin

Darth Vader #20

Ondo