I am trying to create a mercurial repository in a directory whose name includes dollar signs. This is an equivalent and simplified example of what i get on windows 10 cmd.exe with mercurial 4.1.3 :
C:\test\dir1>hg init
C:\test\dir1>hg status
C:\test\dir1>cd ../dir$$1
C:\test\dir$$1>hg init
C:\test\dir$$1>hg status
abort: repository C:\test\dir$$1 not found!
so i hope this is clear, the only difference seems to be the dollar signs in the second directory name. thanks in advance!
Mercurial seems to treat dollar signs as an environment variable escape:
C:\test>set X=abc
C:\test>echo $X # Not the shell expanding it, that would be %X%.
$X
C:\test>hg init $X
C:\test>dir
Volume in drive C has no label.
Volume Serial Number is CE8B-D448
Directory of C:\test
11/10/2017 09:27 PM <DIR> .
11/10/2017 09:27 PM <DIR> ..
11/10/2017 09:27 PM <DIR> abc
0 File(s) 0 bytes
3 Dir(s) 53,899,231,232 bytes free
Mercurial has expanded $X as an environment variable. Also:
C:\test>hg init dir$$x
C:\test>dir
Volume in drive C has no label.
Volume Serial Number is CE8B-D448
Directory of C:\test
11/10/2017 09:30 PM <DIR> .
11/10/2017 09:30 PM <DIR> ..
11/10/2017 09:30 PM <DIR> dir$x
0 File(s) 0 bytes
3 Dir(s) 53,899,091,968 bytes free
Two dollar signs insert one dollar sign. When you are in a directory named dir$$x, Mercurial is using dir$x for the name. I found a workaround with hg -R. status, but better to avoid dollar signs.
this has been entered as a Mercurial bug : https://bz.mercurial-scm.org/show_bug.cgi?id=5739
Related
when I try "dir" I get:
02/13/2020 03:29 PM <DIR> Saved Games
02/13/2020 03:29 PM <DIR> Searches
02/16/2020 12:57 PM <DIR> Videos
1 File(s) 0 bytes
16 Dir(s) 21,887,438,848 bytes free
<<<<<<<this new line is what I want to delete or disable
I tried commands like
findstr "." test.txt > output.txt
but they all add that new line at the end.
Thank you
EDIT:
I export "dir /B" to a file > output.txt
I need this because another program uses the list, and the last new line crashes it.
The program that loops through that list is hardcoded, so I need to provide it a list without the blank line.
This is unrelated to Java, however the error occurs when I try to compile my code.
The semicolon in the command is causing Windows cmd to fail
Example
c:\>cd c:\windows <- no error
c:\>cd c:\windows; <- the semicolon is not being used a command separator but as part of the path
The system cannot find the path specified.
cmd doesn't use semicolon as a command separator. If you want to have two commands on the same line, you need to use & or | (depending on what you're trying to do).
; is used as an argument separator on Windows, but it's not supported by most applications. It has nothing to do with cmd, and cmd isn't supposed to deal with it (applications parse their command lines, not cmd). It also doesn't apply to cmd intrinsics like cd (cd is not an application).
If you have a directory with a semicolon in the name try wrapping it in "double quotes."
Can't exactly verify your problem, but see below.
Z:\[]>dir
Volume in drive Z has no label.
Volume Serial Number is CAC7-078B
Directory of Z:\
11/27/2019 08:53 <DIR> .
11/27/2019 08:53 <DIR> ..
0 File(s) 0 bytes
2 Dir(s) 871243935744 bytes free
Z:\[]>md zz
Z:\[]>md zz;
A subdirectory or file zz already exists.
Z:\[]>md "zz;"
Z:\[]>dir
Volume in drive Z has no label.
Volume Serial Number is CAC7-078B
Directory of Z:\
11/27/2019 08:54 <DIR> .
11/27/2019 08:54 <DIR> ..
11/27/2019 08:54 <DIR> zz
11/27/2019 08:54 <DIR> zz;
0 File(s) 0 bytes
4 Dir(s) 871243935744 bytes free
Z:\[]>cd zz;
Z:\zz;[]>cd ..\zz
Z:\zz[]>cd "..\zz;"
Z:\zz;[]>
The issue has been resolved with the following
Adding -J-Djdk.lang.Process.allowAmbiguousCommands=true to netbeans_default_options= in etc/netbeans.conf
The output from the compile command has not changed, however it now finds the directories???
Trying to copy from command line a file named "SCOOTE~1.txt" to a folder where there is a file called "Scooter - Cosmos.txt".
The problem is that copy will contract the name of "Scooter - Cosmos.txt" to "Scoote~1.txt" as well and will ask if I want to overwrite that file.
How can I literally copy the "SCOOTE~1.txt" without affecting other long-named files ? Suggestion of external command-line tools is accepted.
Recreation of Problem
c:\Test> > "Scooter - Cosmos.txt" echo File with long name
c:\Test> md SFN
c:\Test> > "SFN\SCOOTE~1.TXT" echo File with short name
c:\Test> dir/s/x
Volume in drive C is OS
Volume Serial Number is BE3C-8BC1
Directory of c:\Test
22/09/2017 08:51 <DIR> .
22/09/2017 08:51 <DIR> ..
22/09/2017 08:50 21 SCOOTE~1.TXT Scooter - Cosmos.txt
22/09/2017 08:51 <DIR> Test
1 File(s) 21 bytes
Directory of c:\Test\SFN
22/09/2017 08:51 <DIR> .
22/09/2017 08:51 <DIR> ..
22/09/2017 08:51 22 SCOOTE~1.TXT
1 File(s) 22 bytes
Total Files Listed:
2 File(s) 43 bytes
5 Dir(s) 104,170,942,464 bytes free
Here the current directory has a file with a long-name of Scooter - Cosmos.txt and a short-name of SCOOTE~1.TXT (Note: the short-name is already in place at this stage). Also, the directory SFN contains a file called SCOOTE~1.TXT – because this name "fits" in the 8.3 format, it does not have a separate short-name.
If we now try to copy this file into the current directory, because the short-/only name of the file being copied matches the short-name of the file already present, it prompts about overwriting:
c:\Test> copy "SFN\SCOOTE~1.TXT"
Overwrite c:\Test\SCOOTE~1.TXT? (Yes/No/All): n
0 file(s) copied.
Single-Instance Fix
As eryksun suggested, you can use the fsutil file setshortname command to fix one-off clashes by changing the short-name of the file in the current directory:
c:\Test> fsutil file setshortname "Scooter - Cosmos.txt" SCOOTE~2.TXT
c:\Test> dir/x
Volume in drive C is OS
Volume Serial Number is BE3C-8BC1
Directory of c:\Test
22/09/2017 09:09 <DIR> .
22/09/2017 09:09 <DIR> ..
22/09/2017 08:50 21 SCOOTE~2.TXT Scooter - Cosmos.txt
22/09/2017 08:51 <DIR> SFN
1 File(s) 21 bytes
3 Dir(s) 104,168,501,248 bytes free
c:\Test> copy "SFN\SCOOTE~1.TXT"
1 file(s) copied.
c:\Test> dir/x
Volume in drive C is OS
Volume Serial Number is BE3C-8BC1
Directory of c:\Test
22/09/2017 09:09 <DIR> .
22/09/2017 09:09 <DIR> ..
22/09/2017 08:50 21 SCOOTE~2.TXT Scooter - Cosmos.txt
22/09/2017 08:51 22 SCOOTE~1.TXT
22/09/2017 08:51 <DIR> SFN
2 File(s) 43 bytes
3 Dir(s) 104,168,464,384 bytes free
Here we can see that the short-name of Scooter - Cosmos.txt has been changed so that it no longer clashes with SCOOTE~1.TXT; the copy proceeds with no warning and both files sit side-by-side in the current directory.
Multiple-Instance Fix
If there are (or could be) several clashes with the files in the target directory, an alternative approach is to use the fsutil 8dot3name strip command to remove the 8.3-format short-names from all files at once:
c:\Test> fsutil 8dot3name strip .
Scanning registry...
Total affected registry keys: 0
Stripping 8dot3 names...
Total files and directories scanned: 2
Total 8dot3 names found: 1
Total 8dot3 names stripped: 1
For details on the operations performed please see the log:
"C:\Users\xxxxxxxx\AppData\Local\Temp\8dot3_removal_log #(GMT 2017-09-22 08-36-00).log"
c:\Test> dir/x
Volume in drive C is OS
Volume Serial Number is BE3C-8BC1
Directory of c:\Test
22/09/2017 09:36 <DIR> .
22/09/2017 09:36 <DIR> ..
22/09/2017 08:50 21 Scooter - Cosmos.txt
22/09/2017 09:33 <DIR> SFN
1 File(s) 21 bytes
3 Dir(s) 104,154,349,568 bytes free
As can be seen, the file Scooter - Cosmos.txt no longer has a short-name, so there is no clash when SCOOTE~1.TXT is copied into the current directory:
c:\Test> copy "SFN\SCOOTE~1.TXT"
1 file(s) copied.
c:\Test> dir/x
Volume in drive C is OS
Volume Serial Number is BE3C-8BC1
Directory of c:\Test
22/09/2017 09:40 <DIR> .
22/09/2017 09:40 <DIR> ..
22/09/2017 08:50 21 Scooter - Cosmos.txt
22/09/2017 08:51 22 SCOOTE~1.TXT
22/09/2017 09:33 <DIR> SFN
2 File(s) 43 bytes
3 Dir(s) 104,151,703,552 bytes free
NOTE: The first stage of this command – Scanning registry... – may take some time as it is looking through the registry for references to the 8.3-format names that are about to be removed. See fsutil 8dot3name strip /? for more details of this command.
Caution (Applies to both methods)
As the help from the fsutil 8dot3name strip /? command says:
This command permanently removes 8dot3 file names from your volume. It
will list the registry keys pointing to the stripped 8dot3names but
will not modify the affected registry keys. Stripping will not be
performed on files with full path names longer than the maximum path
length of 260 characters.
both these commands modify (or remove) the 8.3-format names of selected files. If you have any references to the files concerned (either in the registry, configuration files, or elsewhere in .BAT files etc.) then these references will no longer be valid. Use either solution with due caution.
Windows 7/NTFS and later has both symbolic links and junctions, and they are subtly different. (See this excellent set of posts). For logging (and debugging) purposes, I need to be able to resolve the target of a junction on a remote file server. There have been some posts on this topic, but they apply to resolving a junction as the local machine see it.
On \\FileServer, we have a directory G:\Shared that is shared out as PublicShare, so it apears on the network as \\FileServer\PublicShare. Within that directory are sub-directories G:\Shared\SubDir1 and G:\Shared\SubDir2. Also within that directory is a junction G:\Shared\Junc that points to either G:\Shared\SubDir1 or G:\Shared\SubDir2. (The target can change.) Thus, on \\FileServer, one sees
\\FileServer\PublicShare\SubDir1
\\FileServer\PublicShare\SubDir2
\\FileServer\PublicShare\Junc
On a client machine where \\FileServer\PublicShare is mounted (mapped in Windows lingo) as M:\, one thus sees M:\SubDir1, M:\SubDir2, M:\Junc. If, on that client machine, you open a console (cmd.exe) and do dir M:\, Windows gives a nice listing which shows that M:\Junc is a junction and includes the target, G:\Shared\SubDirX, of the junction.
M:\>dir
Volume in drive M is XXXXXXXXX
Volume Serial Number is XXXX-XXXX
Directory of M:\
09/05/2014 07:30 PM <DIR> .
09/05/2014 07:30 PM <DIR> ..
09/05/2014 01:36 PM <JUNCTION> Junc [G:\Shared\SubDir1]
09/06/2014 12:55 PM <DIR> SubDir1
09/05/2014 05:15 PM <DIR> SubDir2
0 File(s) 0 bytes
3 Dir(s) 1,895,493,492,736 bytes free
M:\>
Thus, the target of such a junction is clearly available to a client. Does anyone know how to obtain this information programatically, e.g. which system api to call??? Thanks.
This does the trick:
fsutil reparsepoint query "M:\Junc"
and it seems very reliable.
If you don't want to parse the output of C:\Windows\System32\fsutil.exe, you could simply use DIR:
for /f "usebackq delims=[] tokens=2" %i in ( `dir M:\^|findstr JUNCTION` ) do set RES=%i
Notes:
M:\: you need to display the subfolders (and junctions) of the parent folder of the JUNCTION (in this case: M:\)
findstr: if you have several junctions and want to resolve a specific one, add a |findstr foldername to isolate the right line,
delims=[]: that will divide the output 09/05/2014 01:36 PM <JUNCTION> Junc [G:\Shared\SubDir1] into 3 tokens:
09/05/2014 01:36 PM <JUNCTION> Junc
G:\Shared\SubDir1
"<empty>"
tokens=2: only the second token ("G:\Shared\SubDir1") is of interest
%i: if you run that command in a .bat script, double the '%': %%i in and res=%%i
Just when I'd thought I'd seen it all with Windows path issues, I've now encountered a case that only fails when '/' (forward-slash) is used as the path separator is used:
C:\temp\tcbugs>mkdir "dir1 with spaces"
C:\temp\tcbugs>echo hi > "dir1 with spaces"\foo.txt
C:\temp\tcbugs>type "dir1 with spaces\foo.txt"
hi
C:\temp\tcbugs>type "dir1 with spaces/foo.txt"
The system cannot find the file specified.
What is particularly interesting about this is that it appears to be specific to the cmd.exe shell and doesn't occur in PowerShell (nor presumably in the win32 API):
PS C:\temp\tcbugs> type 'dir1 with spaces/foo.txt'
hi
Another point of interest is that changing directories with 'cd' and using '/' used as a path separator with cmd.exe does work:
C:\temp\tcbugs>mkdir dir2_no_spaces
C:\temp\tcbugs>cd ./dir2_no_spaces
C:\temp\tcbugs\dir2_no_spaces>cd ..
Yet, I can't find any reference to this particular problem anywhere online nor in MSDN's commonly cited documentation:
Naming Files, Paths, Namespaces
Which leads me to ask: why does this happen, and is there a definitive source which documents this quirk?
UPDATE:
dbenham points out that the problem is present regardless of whether spaces are in a directory name, so removed reference to it in the title and question body. Also added an example of 'cd ./' that works, while other commands don't.
Edited to remove opinion
Whether or not Windows CMD.EXE is supposed to support forward slashes in paths, the fact is sometimes it works, sometimes it doesn't, and sometimes it appears to work but gives the wrong result - AKA a bug.
It's time for some experiments :-)
All tests were run on Vista
C:\>md "c:/temp/"
C:\>REM The forward slash works with MD!
C:\>echo hello world 1>>"c:/temp/test.txt"
C:\>REM Redirection works with forward slashes!
C:\>type "c:\temp\test.txt"
hello world
C:\>REM Of course TYPE works with back slashes
C:\>type "c:/temp/test.txt"
The system cannot find the file specified.
C:\>REM But forward slash version fails
C:\>type "c:/temp\test.txt"
hello world
C:\>REM But TYPE works with forward slash as long as last slash is back slash
C:\>dir "c:/temp/test.txt"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
File Not Found
C:\>REM Note how DIR lists the directory with a \, yet fails to find any files
C:\>dir "c:/temp/*"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
File Not Found
C:\>REM DIR Still fails with forward slashes
C:\>dir "c:/temp/"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
05/09/2012 09:58 PM <DIR> .
05/09/2012 09:58 PM <DIR> ..
05/09/2012 09:58 PM 13 test.txt
1 File(s) 13 bytes
2 Dir(s) 337,001,615,360 bytes free
C:\>REM But forward slash works if no file is specified!
C:\>dir "c:/temp\test.txt"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
05/09/2012 09:58 PM 13 test.txt
1 File(s) 13 bytes
0 Dir(s) 337,001,615,360 bytes free
C:\>REM And DIR works with forward slash as long as last slash is back slash
C:\>REM Now add another folder to the path hierarchy
C:\>md "c:/temp/temp/"
C:\>REM Still can create folder using forward slashes
C:\>copy "c:/temp/test.txt" "c:/temp/temp/"
The system cannot find the file specified.
0 file(s) copied.
C:\>REM Failed to copy with forward slashes
C:\>copy "c:/temp\test.txt" "c:/temp/temp/"
1 file(s) copied.
C:\>REM But forward slash works if last slash before file name is back slash
C:\>REM Rerun some past tests
C:\>type "c:/temp/test.txt"
The system cannot find the file specified.
C:\>REM Good - it still fails
C:\>dir "c:/temp/test.txt"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
05/09/2012 09:58 PM 13 test.txt
1 File(s) 13 bytes
0 Dir(s) 337,001,615,360 bytes free
C:\>REM What is going on?! :( Why did that seem to work now?
C:\>REM More on that later.
C:\>REM Now test the new folder
C:\>type "c:/temp/temp/test.txt"
The system cannot find the file specified.
C:\>REM Forward slashes still fail with TYPE
C:\>type "c:/temp/temp\test.txt"
hello world
C:\>REM But forward slash still works as long as last slash is back slash
C:\>dir "c:/temp/temp/*"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp\temp
File Not Found
C:\>REM Again, forward slashes fail, but directory path is listed properly
C:\>dir "c:/temp/temp/"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp\temp
05/09/2012 09:58 PM <DIR> .
05/09/2012 09:58 PM <DIR> ..
05/09/2012 09:58 PM 13 test.txt
1 File(s) 13 bytes
2 Dir(s) 337,001,615,360 bytes free
C:\>REM And again it works if no file is specified
C:\>dir "c:/temp/temp\test.txt"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp\temp
05/09/2012 09:58 PM 13 test.txt
1 File(s) 13 bytes
0 Dir(s) 337,001,615,360 bytes free
C:\>REM Again forward slashes work as long as last slash is back slash
Here is a case that clearly demonstrates a bug.
c:\>dir /s /a-d temp
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
05/10/2012 08:01 AM 13 test.txt
1 File(s) 13 bytes
Directory of c:\temp\temp
05/10/2012 07:57 AM 10 test.txt
1 File(s) 10 bytes
Total Files Listed:
2 File(s) 23 bytes
0 Dir(s) 337,325,191,168 bytes free
c:\>REM Note the different file sizes found in each directory
c:\>dir "c:/temp/test.txt"
Volume in drive C is OS
Volume Serial Number is EE2C-5A11
Directory of c:\temp
05/10/2012 07:57 AM 10 test.txt
1 File(s) 10 bytes
0 Dir(s) 337,325,191,168 bytes free
c:\>REM It is listing the wrong file!
One can debate whether Windows CMD is "supposed" to support forward slashes. But that last result is a bug! Even if there is operator error in using a forward slash, Windows should not give that result.
Wie had some strange behaviour with slash to and we traced it down to the fact, that a path with a leading slash isn't seen as an absolute path, so
C:\>cd /temp
C:\temp>rem works we are in the root directory
C:\temp>cd /temp
Das System kann den angegebenen Pfad nicht finden.
C:\temp>rem does't work but
C:\temp>cd \temp
C:\temp>rem \ indicates absolute path
C:\temp>cd ..
C:\>cd /temp
C:\temp> cd /ca
C:\temp\CA>rem qed
Perhaps it explains also the bug stated above - im not clear, at which directory the commands are executed.
I am not sure why the '/' is working in PS. Back to the history, DOS was based on UNIX and it is a small set of UNIX. In UNIX the path separator is '/', while in DOS it is '\'. I worked on some Windows and DOS apps before. In order to convert some UNIX pattern like commands or path and make sure they are valid DOS command or path, I wrote a small converter to transform '/' to '\' like this:
string fileNameFromWeb;
...
string windowsFile = fileNameFromWeb.repleace("/", #"\");
You may add this feature to tolerant '/' in your app in case of accessing to files in Windows. I guess PS may have this type converter to allow command or path using '/' or '\', or Windows will take '/' in file name.