FTP filenames and spaces

[mbbrutman]

Ah, that is STDIN ending, which means EOF.

I think that what you would like is the existing capability except instead of ending when STDIN ends, it is open ended and continues as an interactive session after stdin is exhausted.

Well, this is getting more complicated ...

If I start FTP with stdin redirected from a file and switch to using the keyboard interactivel using BIOS calls, it works fine. So this lets me start with a script, run a few commands, and then move to interactive use. Which is what I think you are asking for.

But if you shell to DOS, it gets wedged. DOS things that EOF on stdin has been hit (and it has), and you can't type anymore. The only way to escape is to reboot. I tried clearing the EOF flag using the C runtime but that didn't work.

So I'm thinking now that the only way to do this is to provide a command line parameter that says 'run this script' instead of redirecting from stdin. I think that is the only way to do it without having to hit DOS on the head with a hammer and tell it that STDIN is not really gone.

 

[Ole Juul]

So this lets me start with a script, run a few commands, and then move to interactive use. Which is what I think you are asking for.

Yep. Sometimes I just get off on the wrong foot when I try to talk. Logging in some places can be a bit of a chore and it's a lot funner to just type the name of the target location.

So I'm thinking now that the only way to do this is to provide a command line parameter that says 'run this script' instead of redirecting from stdin. I think that is the only way to do it without having to hit DOS on the head with a hammer and tell it that STDIN is not really gone.

Edit: Try here for more lxtcp info and link to sourceforge: http://lxtcp.hplx.net

LXFTP does it like this: "lxftp -f ftp.cmd". I wouldn't be surprised if there was source for that which you could look at, but I don't offhand know where.

 

[Chuck(G)]

I'm not exactly sure that I follow, but why not freopen("CON","rt",stdin) ? That should get stdin back to the keyboard.

 

[CP/M User]

Chuck(G) wrote:

Embedded spaces are perfectly legit in CP/M filenames, as are control characters and lowercase. One of the favorite ways to hide a file back in the old days was to create a name with trailing backspaces. You can't create them if you go through the CCP interface, but that doesn't mean that they aren't supported.

Unfortunately CCP interface was all my CP/M machine knew. Naturally I could have longer filenames or even "Unnamed Files" if I was saving something to Tape, but that was about the limits of having things like Spaces or Longer Filenames. Disc (and yes I mean "Disc") simply didn't allow it! But anyway FTP goes way beyond what I just said!

 

[CP/M User]

vwestlife wrote:

It is also possible to put real spaces into DOS 8.3 file names, if you either hack the FAT or install OS/2. OS/2 had a wonderful habit of creating a hidden file named "EA DATA. SF" on any FAT drive -- including those two "hard" spaces, not Windows 95 long-filename pseudo-spaces.

Now why would you want to go to the trouble?! Would it just be easier to have a HPFS on your computer and simply a Program in DOS to reckonise it! :D

 

[Chuck(G)]

Unfortunately CCP interface was all my CP/M machine knew. Naturally I could have longer filenames or even "Unnamed Files" if I was saving something to Tape, but that was about the limits of having things like Spaces or Longer Filenames. Disc (and yes I mean "Disc") simply didn't allow it! But anyway FTP goes way beyond what I just said! ]

What, you didn't run any application programs or do your own programming? Fill an FCB with whatever you want and issue a CP/M "Make file" system call. You could create a lot of things that not even FTP understands, such as sparse files (i.e. an 8MB file that occupies only 128 bytes on disk). If you want an example of a strange filename created from CCP, just run ASM with no arguments. You get null file names with extensions.

CP/M BDOS is exceedingly stupid and does very little checking.

 

[mbbrutman]

I'm not exactly sure that I follow, but why not freopen("CON","rt",stdin) ? That should get stdin back to the keyboard.

I cleared the EOF flag using clearerr(stdin). In retrospect, what I wanted was to freopen like you suggest. I'll try that.

Either way, making a command line option that takes a filename for a script to execute will work whether the freopen trick works or not.

 

[mbbrutman]

I'm not exactly sure that I follow, but why not freopen("CON","rt",stdin) ? That should get stdin back to the keyboard.

Well Chuck, I've got to hand it to you ... that was masterful.

So here is the question of the moment. Whenever I have referred to the console device, I have done it using "CON:", not "CON". The freopen call didn't like "CON:" with the colon on it, but just plain "CON" worked fine.

Am I just goofy with the colon? I thought that was the way to denote it was a DOS reserved filename. (I'm digging through my DOS books now.)


Mike

 

[Chuck(G)]

Well, C tries to stay as Unix-ish as possible, so I think you'll even find that "\dev\con" will work for the device name (be sure to double up the backslashes so they come through.

CON: is really sort of an early DOS convention, supported for legacy purposes, but frowned upon from within C and tolerated by COMMAND.COM (and CMD.EXE in NT+). In the MS-DOS 2.0 release notes, Microsoft stated the intention to bring DOS and Xenix together at some future point (I still have the notes), so the \dev feature was added for devices and the trailing colon was made optional for everything but drive names.

 

[mbbrutman]

Well, that explains why I'm stuck on the colon - I learned DOS first on DOS 2.1, and I've been writing the device names with colon ever since. And I thought I knew DOS ... ;-0

 

[vwestlife]

I prefer using the colon (such as COPY CON: TEST.TXT or TYPE TEST.TXT > PRN: ) because it explcitly refers to a device, and not a file name. Windows won't let you name a file after one of the reserved device names (CON, AUX, PRN, LPT1, etc.) but the execution is a bit buggy. Try typing EDIT CON.TXT at the command prompt, for example -- the Editor will crash and hang up because it is trying to load the console device as a file!

 

[Chuck(G)]

Well, that explains why I'm stuck on the colon - I learned DOS first on DOS 2.1, and I've been writing the device names with colon ever since. And I thought I knew DOS ... ;-0

DOS 2.0 could be configured to honor the reserved file names only if they were qualified by "\dev"--or for that matter, if you changed the switch character, "/dev/". The option may still be buried somewhere in 2.1, but I suspect it probably never made it as far as DOS 5.0.

This has some wacky effects. If I try to delete a file called "CON", I'll get the message that the file doesn't exist. Okay, so how about if I take an existing file and rename it to "CON"? I get the message that the file already exists. It's a real twilight zone and a potential minefield for programs ported from Unix.

Or, try writing a little C program and use the _dos_findfirst() function to search for the file "CON". You'll get "file not found". But now, search for "\dev\con" and you'll get a valid return. Try it under Windows NT and it'll fail both times.

So, what does your ftp program do when it's called to retrieve a file called, say, "LPT1" on a remote server?

I'm really sorry for opening this can of worms!

 

[mbbrutman]

I imagine that the open on the DOS side is going to barf and return an error. In the case of LPT1 that might be a pretty funny test - I should have a printer hooked up first. ;-0

I test for invalid characters and for filename format. I don't test for reserved words. I might have to add that now.

 

[Chuck(G)]

My little game was a poor attempt to remedy a shortcoming in many FTP clients. There's no way to get "as" a different file name on your own end. The windows client that I use most often (ncftp) does have a "-z" flag on the get for this purpose, but that's far from universal. If I attempt a "get lpt1", ncftp just hangs.

Instead of a reserved word check, you might see if after opening, fstat returns (in st_mode) that the file in question is a device. That should cover installable devices such as "XMSXXXX0", "IFS$HLP$", "SETVERXX" etc.

 

[CP/M User]

Chuck(G) wrote:

What, you didn't run any application programs or do your own programming? Fill an FCB with whatever you want and issue a CP/M "Make file" system call. You could create a lot of things that not even FTP understands, such as sparse files (i.e. an 8MB file that occupies only 128 bytes on disk). If you want an example of a strange filename created from CCP, just run ASM with no arguments. You get null file names with extensions.

CP/M BDOS is exceedingly stupid and does very little checking.

Er? You've confused me now, what are you talking about? I'm just talking about filenames that are 8.3 in length. Unless you're using some 3rd party software for CP/M which allows CP/M to have longer names or spaces in it then I don't see how you would normally do it within a Filename!

 

[CP/M User]

Chuck(G) wrote:

Well, C tries to stay as Unix-ish as possible, so I think you'll even find that "\dev\con" will work for the device name (be sure to double up the backslashes so they come through.

Someone once told me that Unix was actually written in C, which I might have mentioned many times in the forum before! :shocked:

 

[Chuck(G)]

Er? You've confused me now, what are you talking about? I'm just talking about filenames that are 8.3 in length. Unless you're using some 3rd party software for CP/M which allows CP/M to have longer names or spaces in it then I don't see how you would normally do it within a Filename! [/FONT]

Write a small assembler routine that issues a BDOS MAKE FILE request and stuff anything you want into the FCB. Once you've created the file issue a SET FILE POSITION about 2 MB in and write one record, then close the file. Even on a 250K floppy, you'll have a 2MB file that contains only 128 bytes--and it will have junk (including spaces and control characters, if you issued the MAKE FILE call with them in the FCB) for a file name.

This is getting to be OT for Mike's FTP thread, however.

 

[CP/M User]

Chuck(G) wrote:

Write a small assembler routine that issues a BDOS MAKE FILE request and stuff anything you want into the FCB. Once you've created the file issue a SET FILE POSITION about 2 MB in and write one record, then close the file. Even on a 250K floppy, you'll have a 2MB file that contains only 128 bytes--and it will have junk (including spaces and control characters, if you issued the MAKE FILE call with them in the FCB) for a file name.

Oh okay - sounds fascinating!

This is getting to be OT for Mike's FTP thread, however.

That's okay - Mike and Me are old friends from way back! :twisted: And he's more than welcome to turn my Turbo Pascal Website thread into an Assembly yarn!

 

[mbbrutman]

Getting back on topic ..

I posted a new version of the mTCP apps at http://www.brutman.com/mTCP .

The two big changes are support for filename and directory name quoting to allow for embedded spaces and a telnet options negotiation bug fix.

IRCjr and FTP also support high bit characters now. That is probably not of much use because unless you do something special, DOS is using codepage 437 for those values while the rest of the world is probably using a Windows codepage, an ISO codepage, or even Unicode. So don't be disappointed when your special language char shows up correctly on your screen but does not get interpreted correctly on the other side.

Enjoy!
Mike

 

[robdude]

FTP Character ? about Spaces

FTP Character ? about Spaces

Just tried all of the above, Quotes, both double and single, around both words separated by a space, and just in between, also tried backslash, single and double, for good measure even tried forward slash, single than double. None of these worked. They might in a program for FTP, but not at DOS level in windows XP. The CD command will not change to a new directory with a space in the directory name. If someone has another answer, Please let me know. Like one of the other posters on thus page, sometimes we do not have rights to change the name of something stored on someone else's FTP! Even tried a $ since it represented a space on other commands like PROMPT!