Sign in to follow this  
Followers 0
Diana (Cda)

How to make an "include file" for a drive letter?

11 posts in this topic

I just had a fantastic idea that will solve a lot of problems for me. I use all the relative paths tricks in AI for my navigating scripts (i.e, @ScriptDir, @UserProfileDir, etc.). But there are some scripts that absolutely must reference a drive letter since they're launching items on another partition or aren't anywhere in the user profile area, etc. No choices there when dealing with drive letters. This is an issue because after any OS wipe/reinstall, my USB flash drive and large USB drive, get assigned different drive letters. And the partitions all seem to get a different letter each time, too.

But if I have a simple "include" file where I just change the drive letter and reference that file on all the scripts that need it, that would make my life infinitely simpler as I'd never have to edit all those scripts directly for this ever again. After a reinstall, it would just take a quick edit to change the udf (I believe that's the term for the files in the "include" folder, though I could be wrong about that).

I'm thinking something simple in terms of a file that says something like this below. I'm not sure what syntax would be used, though:

$USBflashDriveRootLetter = F

Or whatever it should be.

And then we'd somehow reference it in the scripts. I'm guessing something like this (?):

<#USBlocation.au3>

Thanks. :)

Share this post


Link to post
Share on other sites



$USBflashDriveRootLetter = StringMid(@ScriptDir, 1, 2)

MsgBox(0, 'Usb Device', 'Usb drive letter is ' & $USBflashDriveRootLetter)


AutoIt Scripts:NetPrinter - Network Printer UtilityRobocopyGUI - GUI interface for M$ robocopy command line

Share this post


Link to post
Share on other sites

I just had a fantastic idea that will solve a lot of problems for me. I use all the relative paths tricks in AI for my navigating scripts (i.e, @ScriptDir, @UserProfileDir, etc.). But there are some scripts that absolutely must reference a drive letter since they're launching items on another partition or aren't anywhere in the user profile area, etc. No choices there when dealing with drive letters. This is an issue because after any OS wipe/reinstall, my USB flash drive and large USB drive, get assigned different drive letters. And the partitions all seem to get a different letter each time, too.

But if I have a simple "include" file where I just change the drive letter and reference that file on all the scripts that need it, that would make my life infinitely simpler as I'd never have to edit all those scripts directly for this ever again. After a reinstall, it would just take a quick edit to change the udf (I believe that's the term for the files in the "include" folder, though I could be wrong about that).

I'm thinking something simple in terms of a file that says something like this below. I'm not sure what syntax would be used, though:

$USBflashDriveRootLetter = F

Or whatever it should be.

And then we'd somehow reference it in the scripts. I'm guessing something like this (?):

<#USBlocation.au3>

Thanks. :)

When having at least one NTFS drive in your machine, you can 'redirect' or mount or whatever you'd like to tell it all drives into an empty NTFS directory and get rid of that nasty drives.

I have a German XPP, so all instructions are my personal re-translation and may be wrong:

* Go to the system administration (either via control_panel or a right-click in explorer to 'workplace'

* Activate 'volume menagement'

* Select the volume you'd like to redirect

* right-click and choose 'change drive letter and pathes'

* select <Add> and 'provide in this empty folder'

* navigate to that folder, approve and than remove the drive letter the system had provided

This way you get a fixed 'root path' to that volume that does not collide with drive letters that might have been associated by other means.

Just my 0.02

Share this post


Link to post
Share on other sites

When having at least one NTFS drive in your machine, you can 'redirect' or mount or whatever you'd like to tell it all drives into an empty NTFS directory and get rid of that nasty drives. ...

Hi, thanks! This is great to know. I'll be looking into this and studying this issue in next little while. I didn't know this type of thing was possible. I'm not even entirely sure I understand the whole thing; but I'll begin googling, etc., to explore this in next little while.

Thanks once again. :)

Share this post


Link to post
Share on other sites

$USBflashDriveRootLetter = StringMid(@ScriptDir, 1, 2)

MsgBox(0, 'Usb Device', 'Usb drive letter is ' & $USBflashDriveRootLetter)
Thanks. Interesting. It's not exactly what I need but good idea. I'll see how I can use it in other scripts. Thanks. :)

I've been getting used to variables in last 3 months and I'm now comfortable with them. I've worked them into a lot of my scripts and they're esp. helpful when I put the drive letter at the beginning of a script with a variable then have all subsequent folder paths access that to get the complete path. That saves a whole lot of editing esp. if paths change and I have to edit, i.e., when I switch computers and use my scripts off the thumb drive.

Variables have saved a lot of work, but there is still too much to do sometimes. I started a new contract recently and I still had a lot of re-working to do because of new drive letter for the stick. And computers are locked down at the office so I couldn't make any changes like LuI describes re dealing with drives.

Today at work, I thought about this some more and I'm excited about breaking into a new type of solution for script problems such as this. If I made a file and put it in the "include" folder, then I'd make all pertinent scripts reference that file which would contain the USB flash drive's letter, then I'd never have to rewrite any scripts again. All that would be needed is _one_ change for the USB flash drive after each move to another computer and drive changes. I figure I could also include any other drive letters that are needed, too. Awesome.

Also, I'm hoping that it would be possible to write a box into that file that would prompt when path wasn't good that would also prompt user to enter the drive letter that would then get saved until things change. So no more physical editing of the include file itself ever. In one file, I'd have the solution to this whole problem. I'm hoping at least ...

I know such a thing is possible re error capture, or whatever it's called, because sometimes I've forgotten an include file so when a script that calls on it comes to the missing include, an error box pops up. Or if there is an error in the include file, that, too, pops up a box.

But how would one approach this?

At any rate, here is a basic idea. I'm using variables with variable syntax because that's all I know. I'm guessing the syntax would need to be slightly changed for an include file (??). Anyway, this file could be named something like "_PartitionLetters.au3":

$USBdriveLetter = "F"
  $ProgramsFolder = "L"

Error message box prompting for drive letter when scripts don't work ...
(Perhaps an INI file where drive info is is dumped might work better so there'd be _PartitionLetters.au3 and _PartitionLetters.ini in the include folder(??).)
Then any script needing an absolute path and that couldn't use AI's relative path shortcuts (i.e., @ScriptDir) would work something like this:
<#_PartitionLetters.au3>
; Launch SciTE:
ShellExecute($ProgramsFolder & ":\AutoIt\TOOLS\Editor- SciTE\SciTE v1.74\APP- SciTE v1.74\SciTe.exe")

; Launch AI's icon folder:
ShellExecute($USBdriveLetter & ":\AUTOIT\Scripts\Icons"
Again, I'm not sure about the syntax and am just using variables syntax to illustrate.

Anyway, any help appreciated. Thanks! :)

Share this post


Link to post
Share on other sites

Hi, thanks! This is great to know. I'll be looking into this and studying this issue in next little while. I didn't know this type of thing was possible. I'm not even entirely sure I understand the whole thing; but I'll begin googling, etc., to explore this in next little while.

Thanks once again. :)

Look at the sysinternals commandline Junction tool to create folder "soft links" Care must be taken when removing the link. eg: you can't just delete it, you must use junction to remove the link.

http://technet.microsoft.com/en-us/sysinte...s/bb896768.aspx

Here's some background information:

http://www.shell-shocked.org/article.php?id=284

There's also shell extensions for Explorer that let it better manage such links.

http://alax.info/blog/ntfslinks

http://forge.novell.com/modules/xfmod/project/?ntfslink

One really handy thing with junction / folder links is if you wish to move files (like part of a huge program) onto a secondary drive, you can do so, then point a "link" to the folder without having to reinstall the program, or change the program configuration, because it still "sees" it in the original location.

Share this post


Link to post
Share on other sites

Look at the sysinternals commandline Junction tool to create folder "soft links" Care must be taken when removing the link. eg: you can't just delete it, you must use junction to remove the link.

http://technet.microsoft.com/en-us/sysinte...s/bb896768.aspx

Here's some background information:

http://www.shell-shocked.org/article.php?id=284

There's also shell extensions for Explorer that let it better manage such links.

http://alax.info/blog/ntfslinks

http://forge.novell.com/modules/xfmod/project/?ntfslink

One really handy thing with junction / folder links is if you wish to move files (like part of a huge program) onto a secondary drive, you can do so, then point a "link" to the folder without having to reinstall the program, or change the program configuration, because it still "sees" it in the original location.

Thanks. Will look into this for my home computer. Again, office computers locked up so tight we can't install stuff, so this won't work at office. Which means that it probably won't be a viable solution. I believe my original idea is best, still, since the scripts I create I use equally at home and at office. In other words, I don't create one solution for home and one for work, too much hassle. I create one approach and use for both situations.

But thanks for links. Much appreciated. I'll learn something from this for sure. Cheers. :)

Share this post


Link to post
Share on other sites

Thanks. Interesting. It's not exactly what I need but good idea. I'll see how I can use it in other scripts. Thanks. :)

At any rate, here is a basic idea. I'm using variables with variable syntax because that's all I know. I'm guessing the syntax would need to be slightly changed for an include file (??). Anyway, this file could be named something like "_PartitionLetters.au3":

$USBdriveLetter = "F"
  $ProgramsFolder = "L"

Error message box prompting for drive letter when scripts don't work ...
(Perhaps an INI file where drive info is is dumped might work better so there'd be _PartitionLetters.au3 and _PartitionLetters.ini in the include folder(??).)
Then any script needing an absolute path and that couldn't use AI's relative path shortcuts (i.e., @ScriptDir) would work something like this:
<#_PartitionLetters.au3>
; Launch SciTE:
ShellExecute($ProgramsFolder & ":\AutoIt\TOOLS\Editor- SciTE\SciTE v1.74\APP- SciTE v1.74\SciTe.exe")

; Launch AI's icon folder:
ShellExecute($USBdriveLetter & ":\AUTOIT\Scripts\Icons"
Again, I'm not sure about the syntax and am just using variables syntax to illustrate.

Anyway, any help appreciated. Thanks! :)

_PartitionLetter.au3

Global $USBdriveLetter = StringMid(@ScriptDir, 1, 2)
Global $ProgramsFolder = 'L'

If Not FileExists($USBdriveLetter & '\' & $ProgramsFolder) Then
    $USBdriveLetter = FileSelectFolder('Select Folder', "::{20D04FE0-3AEA-1069-A2D8-08002B30309D}")
    If @error = 1 Then Exit
    $USBdriveLetter = StringMid($USBdriveLetter, 1, 2)
EndIfoÝ÷ Ù«­¢+Ø¥¹±Õ±Ðí}AÉѥѥ½¹1ÑÑÉ̹ÔÌÐì(ì1Õ¹ M¥Qè)M¡±±áÕÑ ÀÌØíUM É¥Ù1ÑÑȵÀìÌäìÀäÈìÌäìµÀìÀÌØíAɽɵͽ±ÈµÀìÅÕ½ÐìÀäÈíÕѽ%ÐÀäÈíQ==1LÀäÈí¥Ñ½È´M¥QÀäÈíM¥QØĸÜÐÀäÈíA@´M¥QØĸÜÐÀäÈíM¥Q¹áÅÕ½Ðì¤((ì1Õ¹ $ÌäíÌ¥½¸½±Èè)M¡±±áÕÑ ÀÌØíUM    É¥Ù1ÑÑȵÀìÅÕ½ÐìÀäÈíUQ=%PÀäÈíMÉ¥ÁÑÌÀäÈí%½¹ÌÅÕ½Ð

AutoIt Scripts:NetPrinter - Network Printer UtilityRobocopyGUI - GUI interface for M$ robocopy command line

Share this post


Link to post
Share on other sites

Danny35d, thank you so much!! I really need to see a working example at first to figure things out later and this was perfect!

I didn't realize that simple variables syntax would also work here. Don't know why not now, in hindsight; probably due to my whole scripting inexperience in general, I suppose. Anyway, I'll be able to really work with this.

I've had to re-think the error box angle. I just don't have the knowledge to automate as much as that would require. That's okay. I'm thinking a very newbie yet easy solution would require little effort. I can build a GUI (god, that's great to be able to say that now!! <lol>) that will open that include file in SciTE. In that same box I'll add buttons that will each send a variable name (i.e., $Fldr_AutoIt_dataFldr_DriveLtr) to the clipboard, because that will be the only "challenging" part to this whole thing.

This solution is more down and dirty vs. programatically elegant in writing this all in, but in a matter of seconds upon arriving at a new job contract, I'd be able to re-set the drive letters for anything, esp. of course for the USB drive. All the scripts would continue to work at home, too, since it's as easy to work with this concept in the include file with any installation in mind. It's as easy to work with variables in the include file as it is when everything is all on one, regular script. There's only the lack of having SciTE tell me the variable names; but the extra buttons solution above would get rid of that.

A quick edit on both files and this is what I have so far. It'll require some finetuning, of course, but here's something ready to work with:

_PartitionLetters.au3

;  1.  USB flash drive:
$USB_DriveLtr = 'P'

;  2. PROGRAMS folder partition:
$Fldr_Programs_DriveLtr = 'L'

;  3.  Partition AUTOIT data folder located on:
$Fldr_AutoIt_dataFldr_DriveLtr = 'E'oÝ÷ ØÖ­º¶¥*)íè§r[yú%uêÀÚ'zÇ+m«ZqǬ±ë6¡ûayÚâ½ënÞjëh×6#include <_PartitionLetters.au3>
AutoItSetOption("WinTitleMatchMode", 2)     ; this allows partial window titles to be valid!

; Launch SciTE:
ShellExecute($USB_DriveLtr & ":\APPS\AutoIt\TOOLS\Editor- SciTE\SciTE v1.74\APP- SciTE v1.74\SciTe.exe", "", "", "open", @SW_MAXIMIZE)
WinWait("SciTE")
Sleep(1000)

; Launch AI's icon folder:
ShellExecute($Fldr_AutoIt_dataFldr_DriveLtr & ":\AUTOIT\Scripts\Icons", "", "", "open", @SW_MAXIMIZE)

I can't thank you enough. So far, so very, very good. This is going to save me tons of work. I'm going to be doing musical chairs at my new place of work soon. I've been brought in to replace people as they go on holiday so I'm going to be at different computers in upcoming weeks. If all goes well, moving the memory stick around will require only a 5 second edit on the _PartitionLetters.au3 script.

But not only that, I get 2 for the price of 1! Whenever I have to do an OS wipe/reinstall here at home and drives get changed, rather than doing any major fiddling, I just the other folder root locations!

Unbelievable!

Cheers. :)

Share this post


Link to post
Share on other sites

Just thought that I can actually go back to writing the variables with the fuller drive letter info, F:\ instead of F. I'd gotten into the shorter habit because some of my scripts had many paths. For example, the most complex script launched about 20 items and it was just easier to change 1 little letter than worry about everything. So I'd have this:

;  change drive letter whenever needed:
$variable = 'F'

; launch item 1
ShellExecute($variable & ":\........path......."
....

all the way down to 

; launch item 20
ShellExecute($variable & ":\........path......."
But since there would be so little editing, just some miniscule changes to the _PartitionLetters.au3, can go back to more standard-seeming letter references.

I didn't want to confuse anybody with the above syntax where the ":" appears. <g>

Thanks. :)

Share this post


Link to post
Share on other sites

You could also look at making a script that could automatically figure out what drive is what by using Drivegetdrive() to find what drives exist on the computer

Then use DriveGetLabel() or maybe Fileexists to see what a given drive is.

Here's a piece of code that I whipped up but haven't tested. It will try to read the drive values from an ini file, where each computer will have their own section. If the section doesn't exist, it will figure out what drive's what, then save to the ini file. Each drive is in the "F:" format.

Global $USB_DriveLtr
Global $Fldr_Programs_DriveLtr
Global $Fldr_AutoIt_dataFldr_DriveLtr
$inidriveletters=IniReadSection(@ScriptDir & "\driveletters.ini",@ComputerName)
If @error==1 Then

    Finddrives()
Else 
    For $i=1 to $inidriveletters[0][0]
        If $inidriveletters[$i][0] =="USB_DriveLtr" Then
            $USB_DriveLtr=$inidriveletters[$i][1]
        ElseIf $inidriveletters[$i][0] =="Fldr_Programs_DriveLtr" Then
            $Fldr_Programs_DriveLtr=$inidriveletters[$i][1]
        ElseIf $inidriveletters[$i][0] =="Fldr_AutoIt_dataFldr_DriveLtr" Then
            $Fldr_AutoIt_dataFldr_DriveLtr=$inidriveletters[$i][1]
        EndIf
    Next
    
EndIf

    

Func Finddrives()
    $var = DriveGetDrive( "all" )
    If NOT @error Then
        MsgBox(4096,"", "Found " & $var[0] & " drives")
        For $i = 1 to $var[0]
            If DriveGetLabel($var[$i]) == "USBFLASH" Then
                $USB_DriveLtr=$var[$i]
            ElseIf DriveGetLabel($var[$i]) == "Programs" Then
                $Fldr_Programs_DriveLtr=$var[$i]
            ElseIf DriveGetLabel($var[$i]) == "AUTOIT" Then
                $Fldr_AutoIt_dataFldr_DriveLtr=$var[$i]
            EndIf
        Next
        IniWriteSection(@ScriptDir & "\driveletters.ini",@ComputerName,"USB_DriveLtr="& $USB_DriveLtr&@LF   & "Fldr_Programs_DriveLtr="& $Fldr_Programs_DriveLtr&@LF &"Fldr_AutoIt_dataFldr_DriveLtr=" & $Fldr_AutoIt_dataFldr_DriveLtr)
    EndIf
    
EndFunc

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0