Hi Khaled,
I found a little bug in the /run command .
This message board seems to have a similar problem, so replace any "_" with a space).

Example: I have the file "bau__bau.jpg" in drive C:\


in mIRC I type: //run C:\bau__bau.jpg
The filename contains two contiguous spaces, but mIRC tries to open the file "bau bau.jpg" that has only one space in the name.
But that file doesn't exist, so I have the error:
* /run: unable to open 'C:\bau bau.jpg'

It also happens if I type: //run $shortfn(C:\bau__bau.jpg) ; it also happens if I use -n & -p parameters.

I hope this little bug can be fixed.

mIRC has never supported double (or more) spaces, also, it's not only the /run command that will have a problem with this, it's any command which uses an external file. (/readini, /splay, etc.)

In my opinion, it's not mIRC's fault, you should name your files correctly and you won't have problems.

woho, I also think it is a bug, try to do the following:
//echo 1 $findfile(c:\,*.exe,1,echo $1-)
you'll see that mirc 'found' c:\r_e.exe instead of c:\r__e.exe , so, it should be corrected, because, obviously file handling is not correct.

If it's not a bug, then tell us the solution for that occasion, not "you should name your files correctly"...
what is correctly? :P

Greets.

I have never heard of a situation where a file requires that it's named in a way where there are two or more consecutive spaces. So, with that being said, I would say the correct manner in which a file should be named is no more then one space dividing each word, or no spaces at all.

All commands have this "problem". Seeing why is pretty simple: parameters are space dilimited, while in most other languages (and mIRC's identifiers) they're comma delimited.

I know that, my argument is that mIRC shouldn't be to blame or changed because people are too lazy to remove an unneeded space from the name of a file.

There is nothing "incorrect" about putting multiple spaces in a filename, but it is pointless. This isn't a bug, per se, but a consequence of the way that the script parser works. I don't know what point i'm making. I guess just that I see both sides of this, and don't know which I most support. One way around the problem is to use short filenames, which you can get from $findfile with the .shortfn prop.

One interesting thing i found is that $shortfn(a<2 spaces>b.txt) doesn't work, but $shortfn($replace(a--b.txt,-,$chr(32))) does. Perhaps something could be done to correct that, instead of changing so much more to resolve this little issue. It's also possible that i don't know what i'm talking about, and that it is really the same issue.

"All commands have this "problem". Seeing why is pretty simple: parameters are space dilimited, while in most other languages (and mIRC's identifiers) they're comma delimited."

All of you who have stated that this is not a bug, "because of the way mIRC works with the space delimiter" are wrong, why? In every RegEx like software, delimiter (like blank space) closed in the quotation marks, is no longer delimiter. It's just an ordinary character, like all the others, and the statement like "file__.exe" is perfectly correct.

Naming the files "correctly" hmh, what should Bill Gates say, if we ask him to forbid multiple blanks in the filenames? it would be ok, I suppose, but it would be a nonsense, considering that the quotation marks do the job.

So, why should we make limits and check for the "correct" file names if we dont have to? what if you deploy a script, and the script-user has already named files in such a way? Will you blame him, because your script is not working well??
Well, I won't do that. I'll try to find the way to leave the filenames like they are, and try to workaround in the mIRC to get the results...

This is a bug

You have a rather odd definition of "bug".



I would call that "lack of support for quoted strings". It's just something that hasn't been implemented, ie a missing feature if you will. It's certainly not something that doesn't work as intented by the author.

I'd tell you to post in Feature Suggestions, if the feature hadn't already been suggested many times.

I am generally not one for namecalling, but what kind of clown makes assumptions like "people are too lazy to rename their files" in a case where the files are clearly listed, and with the name changed so that they are invalid?

If anything, it should automatically truncate unsupported filenames to their short 8-character version.

Seifer, I am pretty sure you are not the payed P.R. spokesperson for mIRC, so don't spin some "you are just lazy" reply onto a perfectly legitimate topic.

Ok, all of you relax please.
The problem is clear, the cause as well. Wether something will be done to change or fix this is up to Khaled.