Shell script fails: Syntax error: "(" unexpected

I am trying to write a script to copy some files and I get the error:

Shell script fails: Syntax error: "(" unexpected ...

I am using both the special characters ( and the ) and the [ and the ] so how do you copy a file from one drive to another with shell script?

(This command works from a command line but not from a shell script)

Example:

#!/bin/sh
cp -R "/mnt/sdb2/_BurnVideos/MyGreatestMovie(1984) [DVD].mp4"  /mnt/sda2/Movies

For what it's worth this script worked fine for me:

#!/bin/sh
cp -R "/root/test [298](rge).txt" /tmp/test2

What is the filesystem in both sda2 and sdb2?

Going from NTFS to EXT4

Actually that line is 10 lines down into the script and the script gets the error that this issue is on line 10 but apparently the error keeps anything from happening.

No-one can help you until you share the entire script: the problem can on one line, but the shell interpreter would companion about a command many lines below.

1 Like

It’s just a long list of videos to copy from one drive to the other. The need for it came up when I was already two hours into a singly line directory to directory bulk copy and I had a failure and I didn’t want to start over again. So I decided to creat a script by doing a LS of the two directories to see what had not been copied from a previous PuTTY lock-up and to keep me from having to start from scratch . I found some other special characters in the script and removed them but then it started telling me the directory names I specified were not valid directories, so I decided that 6 hours into a simply copy process was long enough to try to recover from a bulk copy command tha failed.

So I started reading and I discovered the –u option of the cp command which says update, so this way I can start a bulk copy going again and know I’m not starting from scratch and this also prevents from having to do hours of syntax study trying to figure out some quirk of Linux which makes what looks like a simple script file fail. I started the command cp -R -u /mnt/sdb2/_BurnVideos/* /mnt/sda2/Movies and at last it seems to have picked up where the previous copy failed. So I am going to leave it at that. (All the little cookbooks online are great except they never seem to cover what to do if your files and directories are full of spaces and funny characters.)

But I do thank everyone for their help.

Use escape character \

I will try that, thank you.

I just hit another problem but luckily after a few hours it dawned on me what was going on. Using the standard "cp -u source destination" command to copy a batch of video files from a USB drive to the espressobin built-in SATA controller and a drive connected to it, I finally got all the files copied from the USB to the permanent drive with this latest iteration by skipping using a script and just doing a global copy with the update or -u option. Now the problem showed up. With a Windows 7 machine, I could view any video that was on the SATA controller permanent drive, both the old ones and the new ones I had copied could be managed equally. However on an Android TV appliance with Kodi, I could view the old movies but not the new movies. What I found was the cp (copy) routine copied all the files and directories to the existing drive with a permission of 500. When I changed the permission to 755 (the permission that was assigned to new files via the Windows Samba4 share then all of a sudden the android based kodi app would play all files.

So the short story to be discovered here is, apparently file permissions are not adhered to (honored) on a Windows client access of a Samba(4) share on the Linux OpenVPN image. They file permission is honored, however, when the share is accessed from an android device. Nice to know for future bulk copiers moving or copying files from a NTFS to EXTx partition - always check your file permissions after copying (in this case the files were copied from a NTFS USB device to a EXT4 SATA connected internal device and defaulted to 500 while the files copied with Windows system has defaulted to 755)..

Alternatively, instead of quoting your path with double quotes, use single quotes. Anything surrounded in single quotes is not interpreted by the shell and is passed "as-is".

'/your/path/with-(brackets)'

3 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.