$1 variable in shell script working on only half the operation

[qyot27]

I'm really not sure if this is a problem with my environment on Ubuntu, or a problem with the ffmsindex I compiled, or what, but this is the shell script I'm using:
# !/bin/bash -x
ffmsindex "$1"
echo FFmpegSource2\(\"$1\"\)>"$1".avs
Its intent is to index the file, and then generate a compatible AviSynth script. However, when I try running it, ffmsindex fails, saying it cannot open the video file I gave the script, but yet the echo line generates the AviSynth script the way it's supposed to. Strangely, though, when ffmsindex fails it reports the name of the file back properly...it just says there's an indexing error and it can't open it. If I call ffmsindex regularly with the actual file name, it works, but if I use it in a script with the $1 parameter so that the file I call against the script gets substituted, it doesn't.

To try to whittle down the possibilities, I also tested the script under my MSys environment on XP - it worked on both lines without a problem. ffmsindex indexed the file without issue, and the script was generated correctly. But I'm not sure, if it is a problem with my Ubuntu environment, where the offending party is. If it's with ffmsindex, what's different about how it gets called on Linux that it can't process the $1 variable correctly? I also tested with the Windows build using Wine and even it fails, whereas it works on XP. So I'm strongly thinking it is something about the way the environment is set up...although like I said, I don't know what.

[nm]

# !/bin/bash -x

You have an extra space in the shebang, between # and !. That makes the line a comment and may cause some strangeness.

[qyot27]

Taking out the space did make the -x parameter work properly (I'd been wondering why it hadn't been lately), but it didn't solve the problem with ffmsindex. Here is the actual error output on my Ubuntu 9.10 setup:

qyot27@ubuntu-desktop:~/Videos$ ./mkvindex.sh videofile.mkv
+ ffmsindex $'videofile.mkv\r'
Indexing, please wait... 0%

'ndexing error: Can't open 'videofile.mkv
+ echo 'FFmpegSource2("videofile.mkv")'
qyot27@ubuntu-desktop:~/Videos$
It's adding a \r to the end of the filename.



And that warning allowed to me figure out just what was wrong - even though I'd edited the script in gedit plenty of times, it was still retaining one of the carriage returns from Windows, as I'd simply copied the script over first before working with it. I used fromdos on it, and it started working the way it was supposed to. This also explains why MSys was able to use it without issue - it doesn't care what the line endings are, and recognizes both. It's not the first time this has bitten me, as I had to deal with it concerning SVN checkouts before (and it's also the reason why I now use Cygwin's SVN client on Windows instead of a fully-native Windows build - Cygwin uses normal Unix EOLs, so I don't have to worry about it).

[KenD00]

A better solution is to set the property svn:eol-style on all text files accordingly ;).

:rolleyes:

[qyot27]

A better solution is to set the property svn:eol-style on all text files accordingly ;).

:rolleyes:
Maybe it would be - if I could actually get it to work. No matter what, the Windows builds of SVN would only output Windows line endings for me, whether I had those properties explicitly set to LF in the conf file or not.

And considering the Cygwin build works fine without any extra configuring whatsoever, I don't see the problem.

[KenD00]

AFAIK you can't configure the svn client to output a specific line ending, what you can configure is the autoprops feature so that the client sets this property to specific files itself (and this is highly recommended ;)). However, it does this only for newly added files, for exisiting files you have to set this property yourself like
svn propset svn:eol-style LF myscript.sh

:rolleyes:

[qyot27]

All the instructions I ever saw were to define the autoprops option in Subversion's config file (on *nix this is ~/.subversion/config, in Windows it's in C:\Documents and Settings\User\Application Data\Subversion\config), even here it lays it out that way:
http://www.mediawiki.org/wiki/Subversion/auto-props

I don't use TortoiseSVN or any graphical client, but the config file should be practically the same especially from what that page indicates. I did set autoprops to LF...in fact I set every single extension under autoprops to LF, and nothing changed when checkouts happened. I just realized it was still sitting around on my hard drive, and yes, this is what it looks like:
### Set enable-auto-props to 'yes' to enable automatic properties
### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-auto-props = yes
### Set interactive-conflicts to 'no' to disable interactive
### conflict resolution prompting. It defaults to 'yes'.
# interactive-conflicts = no

### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match (case-insensitively) will be
### applied to the file. Note that auto-props functionality
### must be enabled, which is typically done by setting the
### 'enable-auto-props' option.
*.c = svn:eol-style=LF
*.cpp = svn:eol-style=LF
*.h = svn:eol-style=LF
*.dsp = svn:eol-style=LF
*.dsw = svn:eol-style=LF
*.sh = svn:eol-style=LF;svn:executable
*.txt = svn:eol-style=LF
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
Makefile = svn:eol-style=LF
As you can see, all the options are set explicitly to LF, and the enable-auto-props option is set. Yet, when I would do
svn checkout svn://svn.ffmpeg.org/ffmpeg/trunk ffmpeg
to download ffmpeg's source code, the files all used CRLF instead. Because it even says in the comments in config that it works for 'svn add' or 'svn import', I don't see 'svn checkout' mentioned.

The last edit on that config file was December 14, 2009. The date upon which I finally got tired of the options being ignored and copied over the Cygwin SVN install was December 20, 2009. Just to make absolutely sure it wasn't influencing the Cygwin client, this evening I renamed the Application Data directory from 'Subversion' to 'posterblatt' and tried again...still got Unix EOLs like I wanted, without its interference. And this was from plain old cmd.exe, not MSys' rxvt or sh prompts, although it works like that in those too.


The point I'm getting at is that I'm not doing anything 'wrong' for not using a pure Windows build; it's exactly the same as if I were using Cygwin, which at least does work like a POSIX system and sure enough, when the .subversion folder pops up in my MSys $HOME directory, it even has the extensions under auto-props set to 'native', even though the auto-props option is disabled and it only ever reads that config file when I check stuff out while using MSys' shell rather than the normal Windows command prompt. There is no config file it reads (that I know of, anyway) when I use it from cmd.exe.

I don't develop programs (and actually, know squat about programming, so developing's impossible), therefore the 'svn add' and 'svn import' functions that the docs themselves say eol-style and auto-props control are useless to me, because I have zero need to use those aspects of Subversion.