Get the file name and the file directory from a file path

[Rofellos]

These functions are very useful if you got a file path and want the name or the directory of the file.

expandcollapse popup

; #FUNCTION# ======================================================================================================
; Name...........: GetDir
; Description ...: Returns the directory of the given file path
; Syntax.........: GetDir($sFilePath)
; Parameters ....: $sFilePath - File path
; Return values .: Success - The file directory
;                  Failure - -1, sets @error to:
;                  |1 - $sFilePath is not a string
; Author ........: Renan Maronni <renanmaronni@hotmail.com>
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ==================================================================================================================

Func GetDir($sFilePath)

    Local $aFolders = StringSplit($sFilePath, "\")
    Local $iArrayFoldersSize = UBound($aFolders)
    Local $FileDir = ""

    If (Not IsString($sFilePath)) Then
        Return SetError(1, 0, -1)
    EndIf

    $aFolders = StringSplit($sFilePath, "\")
    $iArrayFoldersSize = UBound($aFolders)

    For $i = 1 To ($iArrayFoldersSize - 2)
        $FileDir &= $aFolders[$i] & "\"
    Next

    Return $FileDir

EndFunc   ;==>GetDir

; #FUNCTION# ======================================================================================================
; Name...........: GetFileName
; Description ...: Returns the file name of the given file path
; Syntax.........: GetFileName($sFilePath)
; Parameters ....: $sFilePath - File path
; Return values .: Success - The file name
;                  Failure - -1, sets @error to:
;                  |1 - $sFilePath is not a string
; Author ........: Renan Maronni <renanmaronni@hotmail.com>
; Modified.......:
; Remarks .......:
; Related .......:
; Link ..........:
; Example .......:
; ===================================================================================================================

Func GetFileName($sFilePath)

    Local $aFolders = ""
    Local $FileName = ""
    Local $iArrayFoldersSize = 0

    If (Not IsString($sFilePath)) Then
        Return SetError(1, 0, -1)
    EndIf

    $aFolders = StringSplit($sFilePath, "\")
    $iArrayFoldersSize = UBound($aFolders)
    $FileName = $aFolders[($iArrayFoldersSize - 1)]

    Return $FileName

EndFunc   ;==>GetFileName

[MrCreatoR]

There is already _PathSplit UDF, and also look at my _PathSplitByRegExp() udf.

[Rofellos]

There is already _PathSplit UDF, and also look at my _PathSplitByRegExp() udf.

Yes, but with _PathSplit you have to concatenate the items of the array to get de full directory every time. And I use it a lot. So I made a function to reduce the work.

_PathSplit and _PathSplitByRegExp are actually much more versatile. But some times I need something more specific.

Edited December 23, 2010 by Rofellos

[MrCreatoR]

with _PathSplit you have to concatenate the items of the array to get de full directory every time

Nope:

Dim $szDrive, $szDir, $szFName, $szExt
_PathSplit(@ScriptFullPath, $szDrive, $szDir, $szFName, $szExt)
ConsoleWrite($szDrive & $szDir & @LF)

_PathSplit and _PathSplitByRegExp are actually much more versatile. But some times I need something more specific.

Then here is a simple way for your functions:

Func GetDir($sFilePath)
    If Not IsString($sFilePath) Then
        Return SetError(1, 0, -1)
    EndIf
    
    Local $FileDir = StringRegExpReplace($sFilePath, "\\[^\\]*$", "")
    
    Return $FileDir
EndFunc

Func GetFileName($sFilePath)
    If Not IsString($sFilePath) Then
        Return SetError(1, 0, -1)
    EndIf
    
    Local $FileName = StringRegExpReplace($sFilePath, "^.*\\", "")
    
    Return $FileName
EndFunc

[Rofellos]

Nope:

Dim $szDrive, $szDir, $szFName, $szExt
_PathSplit(@ScriptFullPath, $szDrive, $szDir, $szFName, $szExt)
ConsoleWrite($szDrive & $szDir & @LF)

Then here is a simple way for your functions:

Func GetDir($sFilePath)
    If Not IsString($sFilePath) Then
        Return SetError(1, 0, -1)
    EndIf
    
    Local $FileDir = StringRegExpReplace($sFilePath, "\\[^\\]*$", "")
    
    Return $FileDir
EndFunc

Func GetFileName($sFilePath)
    If Not IsString($sFilePath) Then
        Return SetError(1, 0, -1)
    EndIf
    
    Local $FileName = StringRegExpReplace($sFilePath, "^.*\\", "")
    
    Return $FileName
EndFunc

Yes, thanks!

[michaelslamet]

@Rofellos: thanks for this GetDir and GetFileName function. I sucessfully use it

[TheSaint]

The only element missing from _PathSplit, is just the parent foldername, which funnily enough I always seem to require.

Obviously that's for the name of the folder containing a file - without any path elements.

Perhaps _PathSplit should be amended to ->

_PathSplit(@ScriptFullPath, $szDrive, $szPath, $szDir, $szFName, $szExt)

Edited December 26, 2012 by TheSaint

[guinness]

What's wrong with $szDrive & $szDir? If not then provide an example of what you expect from _PathSplit.

[TheSaint]

I haven't got an install of AutoIt on this machine, so I can't whip up a quick example, that I might make a little error in somewhere manually, but basically ->

C:Program FilesMP3 ToolsMp3TagMp3Tag GUI.exe

With _PathSplit you get ->

$szDrv = C:

$szDir = Program FilesMP3 ToolsMp3Tag

$szFName = Mp3Tag GUI

$szExt = .exe

There is no parent folder name for the file, in this case ->

Mp3Tag

To get that, you have to strip the rest away each time.

In my view, it should be ->

$szDrv = C:

$szPth = Program FilesMP3 Tools

$szDir = Mp3Tag

$szFName = Mp3Tag GUI

$szExt = .exe

All sorts of scenarios require just the parent folder name on it's own ... at least for me, they do.

Essentially, it's the program name in many scenarios, where the executable may be named something else.

EDIT

Of course, in many cases, the $szPth element would have to cope with returning a blank.

C:Mp3TagMp3Tag GUI.exe

Edited December 27, 2012 by TheSaint

[Rux]

I've made some functions that do this as well.

[TheSaint]

I've made some functions that do this as well.

As have many of us no doubt, but share away if you like.

Old codgers like me precede the _PathSplit command, and have often used Functions at hand, and this may be why no one to my knowledge has asked for that improvement.

If I was up on UDF protocols and cared enough, I would have added the improvement myself years ago. This topic brought it to mind, and I thought I'd mention the missing element ... that I've never understood why it was left out.

At a guess, I'd have to say, that I strip away a path for that element more than any other, so it's always been passing strange that it was missing from _PathSplit.

In a sense, it's very much like using _PathSplit twice, to get what you want.

_PathSplit(@ScriptFullPath, $szDrive, $szDir, $szFName, $szExt)

$progname = szDrive & $szDir

_PathSplit($progname, $szDrive, $szDir, $szFName, $szExt)

$progname = $szFName

But then of course you lose the original $szDir & $szFName & $szExt elements unless you store them as other variables. Edited December 27, 2012 by TheSaint

[BrewManNH]

I think that the way _PathSplit returns things the way they do is because sometimes all you have is just a drive letter and a folder name. I think it wouldn't make much sense to return the folder name twice if your file is in, for example, C:Temp, you'd get the Temp part twice. The way it is now, it's a simple matter to use the last backslash in the $szDir as the indicator of the folder name that the path points to.

[guinness]

I care about the UDFs hence why I asked. I can't see any real need to add this as you have to look from the perspective of would this benefit everyone and not just me. Secondly it would be a massive script breaking change, especially if you consider the first part again of whether it would benefit the majority and the language, which the likes of the Word/Excel UDF updates are doing.

Edited December 27, 2012 by guinness

[TheSaint]

I think that the way _PathSplit returns things the way they do is because sometimes all you have is just a drive letter and a folder name. I think it wouldn't make much sense to return the folder name twice if your file is in, for example, C:Temp, you'd get the Temp part twice.

No different than what happens now with $szDir, if the file is in the root of a drive. You code it to only return what is remaining, so I can't see it as that difficult or troublesome.

The way it is now, it's a simple matter to use the last backslash in the $szDir as the indicator of the folder name that the path points to.

As I have been doing.

@guinness - You no doubt know more of the ins & outs of the function than I do, so would know the difficulty involved, plus as you say, script breaking for older scripts and different to what people are used to, but I've seen that happen many times over the years with AutoIt ... and probably most other languages.

I'm just so surprised that the element wasn't thought of and implemented in the first place, first time around. Has always felt like an oversight to me.

Surely I'm not the only one that feels this way, or has wished it was included.

I've created hundreds of programs over the years, and nearly every single one, I've had to use the backslash, which costs another line or two of code each time. I'm not fussed to keep doing it that way though, it's just I've always been bewildered by its lack of inclusion, since someone went to all the trouble of creating _PathSplit ... it just seems so incomplete without it, and negates (for me) half the reason for using _PathSplit in the first place.

Perhaps I do things differently to others in this regard ... though I seriously doubt that.

Short of asking a user to type in a program name, it has to be something we all need to get, quite often?

EDIT

Of course, one way around most of the issues, is to create a new named function, based on the _PathSplit one, that has the missing element, plus a couple more that would be handy.

i.e. _PathSections or _PathElements

_PathSections(@ScriptFullPath, $szDrive, $szPath, $szFilepath, $szDir, $szFile, $szFName, $szExt)

So for ->

C:Program FilesMP3 ToolsMp3TagMp3Tag GUI.exe

you get ->

$szDrive = C:

$szPath = Program FilesMP3 Tools

$szFilepath = C:Program FilesMP3 ToolsMp3Tag

$szDir = Mp3Tag

$szFile = Mp3Tag GUI.exe

$szFName = Mp3Tag GUI

$szExt = .exe

That way, there is no mucking around with extra code to get what you want.

Edited December 27, 2012 by TheSaint

[guinness]

script breaking for older scripts and different to what people are used to, but I've seen that happen many times over the years with AutoIt ... and probably most other languages.

It could be argued that those script breaking changes were beneficial to all and not just a select few.

If there was a need for it then someone by now would have posted a 'feature request' in Trac. If you feel this will benefit not just you but other users, then by all means post a feature request in Trac.

[TheSaint]

It could be argued that those script breaking changes were beneficial to all and not just a select few.

I find it very hard to believe that it would only benefit a few. Most might not care, and have kept quiet about it for years like I have, but I'm sure they would use it regularly if it was there ... or are you telling me it's a rare thing to get the program name for a file from the path?

If there was a need for it then someone by now would have posted a 'feature request' in Trac. If you feel this will benefit not just you but other users, then by all means post a feature request in Trac.

Like I said, I suspect people have just not bothered, they have an alternate way to do things, that may cost a few more lines of code, but is simple/quick enough to employ. And frankly, I mentioned the whole thing, knowing I would just get the response I did, and for once, thought what the heck. Others would be less motivated.

Hence, I doubt I'll bother with Trac, not unless a few come on board with me here.

That's not to say it shouldn't have always been there though, to benefit all.

How you can imagine it would only benefit me, I just don't understand?

Edited December 27, 2012 by TheSaint

[guinness]

And frankly, I mentioned the whole thing, knowing I would just get the response I did, and for once, thought what the heck. Others would be less motivated.

Update _PathSplit with your additions and lets see what the response is. I'm more than happy to add your update if there is a need, but I personally can't see it.

How you can imagine it would only benefit me, I just don't understand?

Because I can't see the real need for _PathSplit to retrieve the parent folder. But as I said I'm more than happy to discuss with others if they feel it would be beneficial.

I get the impression you think I'm arguing, but not at all. I would love to add tons of additions to the UDFs, but in doing so I could not only create hassle for other users, but my reputation and access could be revoked. I only know of water, Mat and me out of the MVPs who are updating the UDFs and help file, so maybe they have a different take on this?

Edited December 27, 2012 by guinness

[AZJIO]

_FO_PathSplit

In each case, you can change for the sake of speed of execution.

[TheSaint]

_FO_PathSplit

In each case, you can change for the sake of speed of execution.

I'm not sure why you linked to that, because from what I read, it's even more limiting than the original _PathSplit and solves nothing?

We are after the name of the folder, that the file is in, not the file.

@guinness - You may not be arguing, but your response was exactly like I suspected, and not what I hoped. And please don't take that personally, because I'm sure most of the other AutoIt team members would have responded in the same way.

I admit, that I was hoping for support from the general user population, if I expected anything, and won't proceed any further without that. Long experience here has taught me that, at least.

But frankly if nothing ever gets said, then change rarely ever happens.

I pipe up every now and then (like I did once again with Titlecase), just to give my support to promoting change of view.

Further to all that, I'm not terribly fussed. If I genuinely cared deeply about this, then I would have amended the function for myself years ago, just like I did with _Propercase/Titlecase, but I haven't bothered ... because it's no big problem for me.

That has no bearing though on what I think should be or my disappointment that others can't see the benefit to all.

EDIT

As a side note. I can remember when _PathSplit was first introduced, and some of the bugs it had, like not coping with a period in a folder name. It seemed poorly implemented to me, and not well thought out, so I avoided it for quite some time.

[guinness]

WinAPIEx has an array of functions that do a safer job than _PathSplit in my humble opinion.

Oh, and I was about to amend _PathSplit as an example, but it appears I don't need to anymore.