How can I specify the name of a mounted drive in Windows when mounting programmatically? - windows

I am writing a perl routine that mounts specific drives at startup. However, when the drives are mounted, they appear in "My Computer" with odd names like "dir$ at 'machinename' (H:)".
Is there a way in perl or C to specify this string (or just the 'dir$' part?) at mount-time?

You question is not entirely clear to me, but do you mean something like File::Spec's splitpath method?
splitpath
Splits a path in to volume, directory,
and filename portions. On systems with
no concept of volume, returns '' for
volume.
($volume,$directories,$file) = File::Spec->splitpath( $path );
($volume,$directories,$file) = File::Spec->splitpath( $path, $no_file
);
For systems with no syntax
differentiating filenames from
directories, assumes that the last
file is a path unless $no_file is true
or a trailing separator or /. or /..
is present. On Unix, this means that
$no_file true makes this return ( '',
$path, '' ).
The directory portion may or may not
be returned with a trailing '/'.
The results can be passed to catpath()
to get back a path equivalent to
(usually identical to) the original
path.

After much searching, one way to do it is by monkeying with the registry--not a great method, but it works
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\DriveIcons\D\DefaultLabel]
will set the visible label for the D: drive, etc.

Related

How to get filepaths that match a glob without having them on the filesystem

I have a list of filepaths relative to a root directory, and am trying to determine which would be matched by a glob pattern. I'm trying to get the same results that I would get if all the files were on my filesystem and I ran Dir.glob(<my_glob_pattern>) from the root diectory.
If this is the list of filepaths:
foo/index.md
foo/bar/index.md
foo/bar/baz/index.md
foo/bar/baz/qux/index.md
and this is the glob pattern:
foo/bar/*.md
If the files existed on my filesystem, Dir.glob('foo/bar/*.md') would return only foo/bar/index.md.
The glob docs mention fnmatch, and I tried using it but found that the pattern foo/bar/*.md was matching .md files in any number of nested subdirectories, similar to what Dir.glob('foo/bar/**/*.md') would, not just the direct children of the foo/bar directory:
my_glob = 'foo/bar/*.md'
filepaths = [
'foo/index.md',
'foo/bar/index.md',
'foo/bar/baz/index.md',
'foo/bar/baz/qux/index.md',
]
# Using the provided filepaths
filepaths_that_match_pattern = filepaths.select{|path| File.fnmatch?(my_glob, path)}.sort
# If the filepaths actually existed on my filesystem
filepaths_found_by_glob = Dir.glob(my_glob).sort
raise Exception.new("They don't match!") unless filepaths_that_match_pattern == filepaths_found_by_glob
I [incorrectly] expected the above code to work, but filepaths_found_by_glob only contains the direct children, while filepaths_that_match_pattern contains all the nested children too.
How can I get the same results as Dir.glob without having the file paths on my filesystem?
You can use the flag File::FNM_PATHNAME while calling File.fnmatch function. So your function call would look like this - File.fnmatch(pattern, path, File::FNM_PATHNAME)
You can see examples related to its usage here: https://apidock.com/ruby/File/fnmatch/class
Don't use File.fnmatch, instead use Pathname.fnmatch:
require 'pathname'
PATTERN = 'foo/bar/*.md'
%w[
foo/index.md
foo/bar/index.md
foo/bar/baz/index.md
foo/bar/baz/qux/index.md
].each do |p|
puts 'path: %-24s %s' % [
p,
Pathname.new(p).fnmatch(PATTERN) ? 'matches' : 'does not match'
]
end
# >> path: foo/index.md does not match
# >> path: foo/bar/index.md matches
# >> path: foo/bar/baz/index.md matches
# >> path: foo/bar/baz/qux/index.md matches
File assumes the existence of files or paths on the drive whereas Pathname:
Pathname represents the name of a file or directory on the filesystem, but not the file itself.
Also, regarding using Dir.glob: Be careful using it. It immediately attempts to find every file or path on the drive that matches and returns the hits. On a big or slow drive, or with a pattern that isn't written well, such as when debugging or testing, your code can be tied up for a long time or make Ruby or the machine Ruby's running on go to a crawl, and it only gets worse if you're checking a shared or remote drive. As an example of what can happen, try the following at your command-line, but be prepared to hit Cntrl+C to regain control:
ls /**/*
Instead, I recommend using the Find class in the Standard Library as it will iterate over the matches. See that documentation for examples.

Bash/shell/OS interpretation of . and .. — can I define ...?

How do . and .., as paths (vs. ranges, e.g., {1..10}, which I'm not concerned with), really work? I know what they do, and use them all the time, but don't fully grasp how/where they're interpreted. Does the shell handle them? The interpreting process? The OS?
The reason why I'm asking is that I'd like to be able to use ... to refer to ../.., .... to refer to ../../.., etc. (up to some small finite number; I don't need bash to process an arbitrarily large number of dots). I.e., if my current directory is /tmp/let/me/out, and I call cd ..., my resulting current directory should be /tmp/let. I don't particularly care if ... etc. show up in ls -a output like . and .. do, but I would like to be able to call cat /tmp/let/me/out/..../phew.txt to print the contents of /tmp/phew.txt.
Pointers to relevant documentation appreciated as well as direct answers. This kind of syntax question is very hard to Google.
I'm using bash 4.3.42, by the way, with the autocd and globstar shell options.
. and .. are genuine directory names. They are not "sort-cuts", aliases, or anything fake.
They happen to point to the same inode as the other name you use. A file or directory can have several names pointing to the same inode, these are usually known as hard links, to distinguish them from symbolic (or soft) links.
If you are on Linux or OS X you can use stat to look at most of the inode metadata - it is what ls looks at. You will see there is an inode number. If you stat . and stat current-directory-name you will see that number is the same.
The one thing that is not held in the inode is the filename - that is held in the directory.
So . and .. reside in the directory on the file system, they are not a figment of the shell's imagination. So, for example, I can use . and .. quite happily from C.
I doubt you can change them - personally I have never tried and I never will. You would have to change what these filenames linked to by editing the directory. If you managed it you would probably do irreparable damage to your file system.
I write this to clarify what has already been written before.
In many file systems a DIRECTORY is a file; a special type of file that the file system identifies as being distinctly a directly.
A directory file contains a list of names that map to files on the disk
A file, including a directly does not have an intrinsic name associated with it (not true in all file systems). The name of a file exists only in a directory.
The same file can have an entry in multiple directories (hard link). The same file can then have multiple names and multiple paths.
The file system maintains in every directory entries for "." and ".."
In such file systems there are always directory ENTRIES for the NAMES "." and "..". These entries are maintained by the file system.
The name "." links to its own directory.
The name ".." links to the parent directory EXCEPT for the top level directory where it links to itself (. and .. thus link to the same directory file).
So when you use "." and ".." as in /dir1/dir2/../dir3/./dir4/whatever,
"." and ".." are processed in the exact same way as "dir1" and "dir2".
This translation is done by the file system; not the shell.
cd ...
Does not work because there is no entry for "..." (at least not normally).
You can create a directory called "..." if you want.
You can actually achieve something like this, though this is an ugly hack:
You can run a command before every command entered to bash, and after every command. For that you trap the DEBUG pseudo signal and set a command to PROMPT_COMMAND, respectively.
trap 'ln -s ../.. ... &>/dev/null | true' DEBUG
PROMPT_COMMAND='rm ...'
With this, it seems like there's an additional entry in the current directory:
pwd
# /tmp/crazy-stuff
ls -a
# . .. ... foo
ls -a .../tmp/crazy-stuff
# . .. ... foo
Though this only works in the current directory, because the symbolic links is deleted after each command invokation. Thus ls foo/bar/... won't work this way.
Another ugly hack would be to "override" mkdir such that it populates every new directory with these symbolic links.
See also the comments on the second answer here, particularly Eliah's: https://askubuntu.com/questions/327126/what-is-a-dot-only-named-folder
Much in the same way that when you cd into some directory subdir, you're actually following a pointer that points to that directory, .. is a pointer added by the OS that points to the parent directory, and I'd imagine . works the same way.

open UNC path with spaces in windows explorer with perl

Hello stackoverflowers,
i'm afraid i can't figure out how to open an UNC path with spaces within Windows Explorer in perl.
Purpose is, i want the user to put a file within the path. To make it more comfortable, the path should open in explorer automatically. Which it does for any local drives.
The UNC path that should open is: \\srvr1\mean space dir
My code so far:
use strict
use warnings
my $sourceDir = "\\\\srvr1\\mean space dir";
system("start $sourceDir");
Which gives the error: "Win can't access \\srvr1\mean."
Ok, so i tried to quote the string:
my $sourceDir = "\\\\srvr1\\\"mean space dir\"";
Which lead to: "Win can't access \\srvr1\"mean space dir"."
Next thing i tried was:
my $sourceDir = q{"\\\srvr1\\mean space dir"}
Which lead to an cmd window being opened with the correct path within the title?!
Is maybe the system call itself wrong?
I really appreciate any help. Thanks.
The second form is correct, but then you have to account for the fact that the start command treats its first quoted argument as a window title. If you want to start a quoted path, you need to give a window title argument too (the empty string is fine).
Like so:
my $sourceDir = q{\\\\srvr1\\mean space dir};
system(qq{start "" "$sourceDir"});
For this kind of thing the array style system call is a good fit. You don't need to worry about quoting the path or escaping as much.
$path = '\\\\srvr1\mean space dir';
system('start', '', $path);
Quoting (or forgetting to quote) paths in system calls is a significant source of bugs where I've worked. A habit of doing it as above means you never need to worry about it.

File::Spec->catpath does not work for Windows

I am using the File::Spec module like this
my $volume = 'C';
my $path = File::Spec->catpath(
$volume,
File::Spec->catdir('panel', 'texts'),
'file'
);
print $path;
output
Cpanel\texts\file
How is File::Spec a portable module, as discussed in How can I construct OS-independent file paths in Perl ...? if I have to write the volume as C:\ and not just C to get it right?
You have 2 problems. The first is that Windows volume names include the colon, so you should have said $volume = 'C:'. The second is that you specified a relative path, so you got a relative path. If you want an absolute path, you have to give one:
use 5.010;
use File::Spec;
my $volume = 'C:';
my $path = File::Spec->catpath($volume,
File::Spec->catdir('', 'panel', 'texts'), 'file');
say $path;
On Windows, that will print C:\panel\texts\file, and on Unix it will say /panel/texts/file.
Note that it's perfectly legitimate to have a relative path with a volume name on Windows:
File::Spec->catpath('C:',
File::Spec->catdir('panel', 'texts'), 'file');
will give you C:panel/texts/file, which means panel/texts/file relative to the current directory on drive C:. (In Windows, each drive has its own current directory.)

In Ruby, how can I interpret (expand) a glob relative to a directory?

Wider context: Case-insensitive filename on case sensitive file system
Given the path of a directory (as a string, might be relative to the current working dir or absolute), I'd like to open a specific file. I know the file's filename except for the its case. (It could be TASKDATA.XML, TaskData.xml or even tAsKdAtA.xMl.)
Inspired by the accepted answer to Open a file case-insensitively in Ruby under Linux, I've come up with this little module to produce a glob for matching the file's name:
module Utils
def self.case_insensitive_glob_string(string)
string.each_char.map do |c|
cased = c.upcase != c.downcase
cased ? "[#{c.upcase}#{c.downcase}]" : c
end.join
end
end
For my specific case, I'd call this with
Utils.case_insensitive_glob_string('taskdata.xml')
and would get
'[Tt][Aa][Ss][Kk][Dd][Aa][Tt][Aa].[Xx][Mm][Ll]'
Specific context: glob relative to a dir ≠ pwd
Now I have to expand the glob, i.e. match it against actual files in the given directory. Unfortunately, Dir.glob(...) doesn't seem have an argument to pass a directory('s path) relative to which the glob should be expanded. Intuitively, it would make sense to me to create a Dir object and have that handle the glob:
d = Dir.new(directory_path)
# => #<Dir:/the/directory>
filename = d.glob(Utils.case_insensitive_glob_string('taskdata.xml')).first() # I wish ...
# NoMethodError: undefined method `glob' for #<Dir:/the/directory>
... but glob only exists as a class method, not as an instance method. (Anybody know why that's true of so many of Dir's methods that would perfectly make sense relative to a specific directory?)
So it looks like I have two options:
Change the current working dir to the given directory
or
expand the filename's glob in combination with the directory path
The first option is easy: Use Dir.chdir. But because this is in a Gem, and I don't want to mess with the environment of the users of my Gem, I shy away from it. (It's probably somewhat better when used with the block synopsis than manually (or not) resetting the working dir when I'm done.)
The second option looks easy. Simply do
taskdata_xml_name_glob = Utils.case_insensitive_glob_string('taskdata.xml')
taskdata_xml_path_glob = File.join(directory_path, taskdata_xml_name_glob)
filename = Dir.glob(taskdata_xml_path_glob).first()
, right? Almost. When directory_path contains characters that have a special meaning in globs, they will wrongly be expanded, when I only want glob expansion on the filename. This is unlikely, but as the path is provided by the Gem user, I have to account for it, anyway.
Question
Should I escape directory_path before File.joining it with the filename glob? If so, is there a facility to do that or would I have to code the escaping function myself?
Or should I use a different approach (be it chdir, or something yet different)?
If I were implementing that behaviour, I would go with filtering an array, returned by Dir#entries:
Dir.entries("#{target}").select { |f| f =~ /\A#{filename}\z/i }
Please be aware that on unix platform both . and .. entries will be listed as well, but they are unlikely to be matched on the second step. Also, probably the filename should be escaped with Regexp.escape:
Dir.entries("#{target}").select { |f| f =~ /\A#{Regexp.escape(filename)}\z/i }

Resources