I seem to have come across a wierd behaviour of GnuWin32's mkdir (from here):
C:\sandbox>"C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE" --verbose -p Q:/scratch/foo/bar
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `Q:/scratch'
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `Q:/scratch/foo'
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `Q:/scratch/foo/bar'
In the above, the current drive is C and the target drive is Q.
As expected, the hierarchy gets created in Q:/scratch/foo/bar
Now, almost the same example but the current and the target drives are both C.
C:\sandbox>"C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE" --verbose -p C:/scratch/foo/bar
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `C:/scratch'
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `C:/scratch/foo'
C:\Program Files (x86)\GnuWin32\bin\mkdir.EXE: created directory `C:/scratch/foo/bar'
mkdir's output looks right and very predictable.
However, nothing really gets created at C:/scratch/foo/bar. Rather, the directory hierarchy gets created using the current directory as a root, i.e. what gets created is C:/sandbox/scratch/foo/bar
Can anyone confirm ? Is this a bug ?
I would look at the source code if I had the time but....
Does anyone know of a more recent version of CoreUtils than 5.3.0 that's been ported to Win32 ?
Looks like a small bug indeed. It seems GnuWin32's port doesn't like the forward slash after the colon following the drive letter. Using backslashes it behaves correctly with both
C:\sandbox> mkdir --verbose -p Q:\scratch/foo/bar
and
C:\sandbox> mkdir --verbose -p C:\scratch/foo/bar
But (as reported) when using forward slashes, it only behaves correctly with
C:\sandbox> mkdir --verbose -p Q:/scratch/foo/bar
(in the above, note the target is on a different drive than the prompt) but not with
C:\sandbox> mkdir --verbose -p C:/scratch/foo/bar
(in the above, note the target is on the same drive as the prompt)
The really old mkdir port from UnxUtils has the correct behaviour all the time. That's the only working alternative I could find.
Related
I'm bit confused with using mqsicreatebar in my environment. I have, for example, following file structure:
root
|--Libraries
| \--Library1
\--Apps
\--App1
\--.project
And App1 is referencing Library1.
I want to run mqsicreatebar such that it will contain App1 with included Library1. I try to run next command in root/Apps folder:
mqsicreatebar -data ./ -b newbarfile.bar -cleanBuild -deployAsSource -a App1 -trace
I get error "Referenced project Library1 is not found on file system". What should I do to create BAR with this file structure?
That "data" parameter tells the mqsicreatebar command where to find an eclipse workspace (Integration Toolkit workspace) that in turn tells the mqsicreatebar command where the project files and other files it needs for the build are.
If you don't have a workspace there already, the command will create one on the fly for you, but only for the current directory and its subdirectories. I do not know how deep this goes. I know it looks at least one subdirectory down for project files (though your comments imply it does not look down two subdirectories).
Alternatively, (and I understand this is not desired, but it's an option, similar to the one you already posted) you could give up on your folder organization and put your library and app subfolders in the same root folder. So you have:
root
|--Library_1
|--Library_2
|--App_1
|--App_2
This is what I have set up in my Bamboo project and the build commands work (even with no workspace files before running the command, as long as I point the data parameter at this root directory).
The only way I've found by myself is copying necessary artifacts to current directory before running mqsicreatebar and deleting them after build completion:
cd /root/Apps/
cp -R ../Libraries/Library1/ ./
mqsicreatebar -data ./ -b newbarfile.bar -cleanBuild -deployAsSource -a App1 -trace
rm -r Library1/
I have a .Jar file, let's call it Test.jar. Inside this file are several directories: Alpha, Beta, Gamma. Alpha and Gamma I don't care about. Beta contains three directories (Uno, Dos, Tres), and those are the ones I want.
I'm trying to use the bash shell on Windows 10, and specifically the unzip command, to target those files and unzip them. The closest I've managed to get looks something like this:
unzip -o C:/directory/test.jar Beta/* -d c:/directory/output
What I would like to see is Uno, Dos, and Tres inside the output folder. Instead, I see nothing.
If I put a file inside the Beta directory (ex. file.txt) and re-run the command, file.txt will be unzipped, but all of the directories are ignores.
If I remove the "Beta/*" from the command unzip happily unzips all directories and files.
I've tried playing around with a wide variety of quotes in different places, but I can't seem to make it work. Any help is appreciated.
Try this
unzip 123.zip -x "Alpha/*" "Beta/*" -d $HOME
That will unzip everthing except the contents of the directories Alpha and Beta into your home profile location named $HOME.
Could you tell me please how to change directory using git bash?
Exactly I want go to C:/Program Files
I type cd c:/ - move to c:/.
I type cd Program Files and I get message that "there is no such directory Program".
So the problem is how to go to the directory name of which consists of two words that are separated by whitespaces.
I'm using Windows 7 operating system.
cd gets just one argument, so if you say cd Program Files it does cd Program. So you need to quote Program Files if you want cd to it as just one argument:
cd "Program Files"
otherwise it is trying to find the directory Program.
You could also type the space as escape seqence:
cd /c/Program\ Files/Git/
Please find below to add windows path in git bash or in unix
export PATH=$PATH:/c/Program\ Files/Java/jdk1.8.0_221/bin:/c/Program\ Files/apache-maven-3.6.1/bin
I read from http://www.techonthenet.com/unix/basic/mkdir.php that the mkdir command "creates a single directories or multiple directories." and that -p "If the parent directories don't exist, this command creates them". I tried this command in cmd(window operating system) and saw that with -p and without -p, the command just created a file with a file name. How do you see the effect of "If parent directories don't exist creates them." I am assuming C:\Users\chris> is the parent directory when i run the command(therefore the parent directory exists). Is there a way of seeing the effect of -p?
Try help.
C:\Users\User>mkdir/?
Creates a directory.
MKDIR [drive:]path
MD [drive:]path
If Command Extensions are enabled MKDIR changes as follows:
MKDIR creates any intermediate directories in the path, if needed.
For example, assume \a does not exist then:
mkdir \a\b\c\d
is the same as:
mkdir \a
chdir \a
mkdir b
chdir b
mkdir c
chdir c
mkdir d
which is what you would have to type if extensions were disabled.
Installing Unix
Unix Services for Windows are either a download from MS website or installed via Control Panel - Programs and Features - Windows Features. Which depends on version and edition of your Windows.
I am using RSync to copy tar balls to an external hard drive on a Windows XP machine.
My files are tar.gz files (perms 600) in a directory (perms 711).
However, when I do a dry-run, only the folders are returned, the files are ignored.
I use RSync a lot, so I presume there is no issue with my installation.
I have tried changing permissions of the files but this makes no difference
The owner of the files is root, which is also the user which the script logs in as
I am not using Rsync's CVS option
The command I am using is:
rsync^
-azvr^
--stats^
--progress^
-e 'ssh -p 222' root#servername:/home/directory/ ./
Is there something I am missing to get my files copied over?
I can think of only a single possibility: My experience with rsync is that it creates the directory structure before copying files in. Rsync may be terminating prematurely, but after this directory step has been completed.
Update0
You mentioned that you were running dry run. Rsync by default only shows the directory names when the directory and all its contents are not present on the receiver.
After a lot of experimentation, I'm only able to reproduce the behaviour you describe if the directories on the source have later modification dates than on the receiver. In this instance, the modification times are adjusted on the receiver.
I had this problem too, and it turns out that backing up to a windows drive from linux doesn't seem to copy the temp files in place, after they are transferred over.
Try adding the --inplace flag, when rsyncing to windows drives.