0

Totally new to Bash here, actually I've avoided it like a plague for 10 years. Today, there is no way around it.

After a few hours of beating my head against the keyboard, I discovered that sudo and any bash variable in a command gets stripped out.

So I have something like

somescript.sh

for i in {1..5}
do
    filename=somefilenumber"$i".txt
    echo $filename
done

on the command line now if I run it 

user@deb:~$ ./somescript.sh

I get the expected

somefilenumber1.txt
somefilenumber2.txt
somefilenumber3.txt
somefilenumber4.txt
somefilenumber5.txt

but if I run with sudo, like user@deb:~$ sudo ./somescript.sh

I'll get this

somefilenumber{1..5}.txt

This is a huge problem because I'm trying to cp files and rm files in a loop with the variable.

So here is the code with cp and rm

for i in {1..10}
do
    filename=somefilenumber"$i".txt
    echo $filename
    cp "$filename" "someotherfilename.txt"
    rm "$filename"
done

I end up getting 

cp: cannot stat 'somefilenumber{1..5}.txt': No such file or directory
rm: cannot remove 'somefilenumber{1..5}.txt': No such file or directory

I need to run sudo also because of other programs that require it.

Is there any way around this? Even if nothing else require sudo, and I don't use it, the rm command will prompt me for every file if I'm sure that I want to remove it or not. The whole point is to not be sitting here tied to the computer while it runs through hundreds of files.

ChumbiChubaGo
  • 578
  • 2
  • 6
  • 14
  • 1
    Sure this is being run with bash, not `/bin/sh`? `{1..10}` is a bashism, so it's expected for `sh` not to expand it. – Charles Duffy Apr 06 '18 at 20:58
  • no i'm not sure. Actually now that you say it, I don't know the difference. – ChumbiChubaGo Apr 06 '18 at 20:58
  • Make sure that the script is looking for the files in the right directory – bwalshy Apr 06 '18 at 20:58
  • 5
    Check that. Make sure your script starts with `#!/bin/bash` or `#!/usr/bin/env bash`, and that you didn't run it with `sh scriptname`. – Charles Duffy Apr 06 '18 at 20:59
  • 2
    @bwalshy, `{1..10}` isn't a glob -- unlike, say, `[0-9][0-9]`, it doesn't care if the files exist or not. – Charles Duffy Apr 06 '18 at 20:59
  • 1
    @CharlesDuffy okay I deleted the .sh from the scriptname. I put #!/bin/bash at the top of the script. Hmm. seems to work. I don't believe it though :D Will be throwing everything I got at it. – ChumbiChubaGo Apr 06 '18 at 21:03
  • 2
    @user3474042, consider running your code through http://shellcheck.net/ for some extra automated feedback/assurance. :) – Charles Duffy Apr 06 '18 at 21:04
  • @user3474042 bash is a specific shell, with a number of added features (like `{1..10}`) that might or might not be available in other shells. `sh` is a generic name for ... well, whatever's included in your OS/distro/whatever as the default shell. It might be bash (with some features disabled for backward-compatibility) or dash (a much more basic shell) or zsh (another advanced shell with *different* features) or ksh or... almost anything. Basically, if you run a script with sh (either by the command `sh` or a `#!/bin/sh` shebang) you cannot count on having any bash extensions. – Gordon Davisson Apr 06 '18 at 23:25

1 Answers1

0

You could try to replace {1..10} with seq 1 10:

for i in `seq 1 10`
do
    filename=somefilenumber"$i".txt
    echo $filename
    cp "$filename" "someotherfilename.txt"
    rm "$filename"
done

Your problem sounds like the environment has something wrong for root, do you start the script with: #!/bin/bash ?

Joonas P
  • 86
  • 1
  • 5
  • 1
    `seq` is not standardized command -- it's not part of bash itself, and it's not POSIX-specified. As such, it's not guaranteed to be available everywhere, and its usage in this manner is *also* dependent on the value of `IFS` -- if you'd set `IFS` to a non-default value, then your `for` loop would iterate only once, having all the numbers inside a single `$i`. – Charles Duffy Apr 06 '18 at 21:13
  • yea I tried seq on this machine, no go. It some distribution of debian that I am not really sure about. Not my system, I have to work in these constraints. – ChumbiChubaGo Apr 06 '18 at 21:17
  • Correct that the problem is sh vs bash. As @CharlesDuffy and you mention, once I put #!/bin/bash in there, and remove the .sh from the script filename, it works fine. Thanks – ChumbiChubaGo Apr 06 '18 at 21:27
  • seq is a part of GNU coreutils, essential packages on debian and its derivatives. I have also some positive tests with arch, fedora, gentoo – kyodev Apr 07 '18 at 01:16