If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Tip: don't use a space at the end of the file name!
Hi All,
Todd made a boo-boo. I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. I don't think I will forget that one for a lot of years! -T |
Ads |
#2
|
|||
|
|||
Tip: don't use a space at the end of the file name!
T on 2017/01/20 wrote:
I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ set bbb=hello%aaa%everyone echo %bbb% |
#3
|
|||
|
|||
Tip: don't use a space at the end of the file name!
On 01/20/2017 05:15 PM, VanguardLH wrote:
T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( |
#4
|
|||
|
|||
Tip: don't use a space at the end of the file name!
T on 2017/01/20 wrote:
On 01/20/2017 05:15 PM, VanguardLH wrote: T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( You did not replace the ^ (carat) characters with spaces as you were warned. Again, "^ represents a space character." So do that in the example command lines. |
#5
|
|||
|
|||
Tip: don't use a space at the end of the file name!
On Fri, 20 Jan 2017 19:15:22 -0600
VanguardLH wrote: I don't know how Cobian uses variables Then STFU |
#6
|
|||
|
|||
Tip: don't use a space at the end of the file name!
On 01/20/2017 09:51 PM, VanguardLH wrote:
T on 2017/01/20 wrote: On 01/20/2017 05:15 PM, VanguardLH wrote: T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( You did not replace the ^ (carat) characters with spaces as you were warned. Again, "^ represents a space character." So do that in the example command lines. Hi Vanguard, I still don't get why you are using the carat escape character "^" to represent a space. Oh I get it. That was for me to replace. I though you meant it literaly. I thought you were escaping something. The tip should have been that there was three of them -T |
#7
|
|||
|
|||
Tip: don't use a space at the end of the file name!
T on 2017/01/21 wrote:
On 01/20/2017 09:51 PM, VanguardLH wrote: T on 2017/01/20 wrote: On 01/20/2017 05:15 PM, VanguardLH wrote: T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( You did not replace the ^ (carat) characters with spaces as you were warned. Again, "^ represents a space character." So do that in the example command lines. I still don't get why you are using the carat escape character "^" to represent a space. Oh I get it. That was for me to replace. I though you meant it literaly. I thought you were escaping something. The tip should have been that there was three of them What do you use as a placeholder character for another that is invisible? If I had used underscores, those typically meld into each other so you couldn't see how many space characters I used in the example. I suppose I could have doubled the lines and shown the command line with another under it with carats showing where are the spaces but then you might've tried entering those lines as commands. |
#8
|
|||
|
|||
Tip: don't use a space at the end of the file name!
On 01/21/2017 01:53 PM, VanguardLH wrote:
T on 2017/01/21 wrote: On 01/20/2017 09:51 PM, VanguardLH wrote: T on 2017/01/20 wrote: On 01/20/2017 05:15 PM, VanguardLH wrote: T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( You did not replace the ^ (carat) characters with spaces as you were warned. Again, "^ represents a space character." So do that in the example command lines. I still don't get why you are using the carat escape character "^" to represent a space. Oh I get it. That was for me to replace. I though you meant it literaly. I thought you were escaping something. The tip should have been that there was three of them What do you use as a placeholder character for another that is invisible? If I had used underscores, those typically meld into each other so you couldn't see how many space characters I used in the example. I suppose I could have doubled the lines and shown the command line with another under it with carats showing where are the spaces but then you might've tried entering those lines as commands. I never use a space at the end of a name. If I want spaces inside the name, I just use a space. I also use dots a lot and sometimes an underscore. Linux would be "\ ". No clue about Windows |
#9
|
|||
|
|||
Tip: don't use a space at the end of the file name!
T on 2017/01/23 wrote:
On 01/21/2017 01:53 PM, VanguardLH wrote: T on 2017/01/21 wrote: On 01/20/2017 09:51 PM, VanguardLH wrote: T on 2017/01/20 wrote: On 01/20/2017 05:15 PM, VanguardLH wrote: T on 2017/01/20 wrote: I set up a Cobian Backup task. I was backing up into a directory called: %DISKLABEL="BACKUP":\MyDocsBackup\backup1 I kept getting two getting two identical directories called "backup1". Both were empty. Cobian said it definitely did copy files to it. So in Windows Explorer (Not IE), I erased both of them. Two seconds after they both disappeared, a single "backup1" came back and this time it had files in it. What the hell? After a bunch of head scratching, I discovered that I had put a space at the end of "%DISKLABEL="BACKUP":\MyDocsBackup\backup1 " -----------------------------------------------^ Removed the space and happy camping returned. So it is a problem in parsing in Cobian, not of Windows (which would've ignored the trailing space). I don't know how Cobian uses variables which seems to be what you used in the above example line. If Cobian was using the equivalent of the command-line 'set' command along with variable substitution then it probably just passes the string to the 'set' command as-is which includes any and all leading and trailing spaces. Try the following in a command shell where ^ represents a space character: set aaa=^^^there^^^ More? set bbb=hello%aaa%everyone More? echo %bbb% hello%aaa%everyone I don't get it. :'( You did not replace the ^ (carat) characters with spaces as you were warned. Again, "^ represents a space character." So do that in the example command lines. I still don't get why you are using the carat escape character "^" to represent a space. Oh I get it. That was for me to replace. I though you meant it literaly. I thought you were escaping something. The tip should have been that there was three of them What do you use as a placeholder character for another that is invisible? If I had used underscores, those typically meld into each other so you couldn't see how many space characters I used in the example. I suppose I could have doubled the lines and shown the command line with another under it with carats showing where are the spaces but then you might've tried entering those lines as commands. I never use a space at the end of a name. If I want spaces inside the name, I just use a space. I also use dots a lot and sometimes an underscore. Linux would be "\ ". No clue about Windows Depends on the parser. For regex, that be "\s", "\s*", "s+", or with other repeat qualifiers (obviously without the double quotes), or even "\s$" to denote at the end of the line and "^\s" at the start of the line? Even C uses quotes to delimite a string constant. So it's a problem with parser seeing a space character that your eyes do not. The parser goes to the EOL character (or NUL to terminate a string in C) so it picks up anything before that as part of the string, including characters invisible to your eye (and why some malware will insert a DEL character in a string that you cannot see, not even a placeholder for it when displayed). |
Thread Tools | |
Display Modes | Rate This Thread |
|
|