Is there any function that will return the path to where the current TB file is located within the file system (sort of like pwd)?
Not offhand, I think! Do you need it, or will something like ā./ā+$FileName suffice?
Not sure, would $FileName contain the fully qualified path of the TB file?. I want to store images and other artifacts externally to the current TB file in the Mac file system. For example, if the TB file is located in say ~Documents/Tinderbox/Daily Journal
, I want to be able to store those artifacts within Daily Journal
in a directory (say Attachments
ā which is given by a user attribute like TbxAttachmentsPath
) that is a peer to the TB file. Assuming there were a function getCWD
, then the path to the Attachments
directory would be getCWD() + '/' + $TbxAttachmentsPath
.
Make sense?
Why not use runCommand. Calling pwd
gives you home folder with is the _appāspwd. But a
findcommand might work. The problem searching from home directory scope it
findwants to search
~/Librarythowing permission errors. But, whilst
~/Documents` used to be a got starting but, things like Dropbox or other Cloud-sync folder are peers of Document as and so out of such scope.
I got this stamp to work:
$MyDoc = eval(^docTitle^) + ".tbx";
$MyRoot = runCommand('pwd').replace("\r","");
$Text = "This file is at:\n" + runCommand("find "+ $MyRoot + $MyFolder + " -name " + $MyDoc );
Action code canāt access the docās name but export code can. You do need the eval()
or the subsequent concatenation fails as Tinderbox things youāre trying to pass a parameter to the export code.
The result of pwd
returns with a trailing carriage return character (i.e. as seen in Terminal output) so that needs removing before building the path. The default shell working director for theTinderbox app is always your home (/users/[yourname]
) folder. Note that the shell find
command cannot interprest the ~
shortcut for the home folder so donāt use it!
In the code above Iām starting in the Documents
folder
If youād prefer the resulting path shorter, e.g. so more readable in Displayed Attributes, then this works:
$MyDoc = eval(^docTitle^) + ".tbx";
$MyRoot = runCommand('pwd').replace("\r","");
$Text = "This file is at:\n" + runCommand("find "+ $MyRoot + $MyFolder + " -name " + $MyDoc );
$Text = $Text.replace($MyRoot,"~");
We can go further and derive the TBX parent folderās parth:
$MyDoc = eval(^docTitle^) + ".tbx";
$MyRoot = runCommand('pwd').replace("\r","");
$MyPath = runCommand("find "+ $MyRoot + $MyFolder + " -name " + $MyDoc );
$Text = "This file is at:\n" + $MyPath + "\nor\n" + $MyPath.replace($MyRoot,"~") + "\nThe TBX's parent folder is:\n" + $MyPath.replace($MyRoot,"~").replace($MyDoc,"");
For real use, Iād convert the attributes used to action code variables. For the āMyFolderā part likely you can hard-code that or you will need an attribute to set the variable. The use of $Text here is mainly to make the result easier to see. You could put the eventual path(s) into attribute(s) if you so choose.
The stamp approach makes sense as it can be re-used in different TBXs.
Here is a demo file (look at its Stamps menu and Stamps Inspector!): pwd.tbx (77.6 KB)
Honestly it did not occur to me to use runCommand
(it should have). Thanks for taking the time to work all this out! Iāll give it a try.
Actually, pwd
prints the current working directory, not the home directory unless the home directory happens to be the current working directory (cwd) (which is likely is in a call to runCommand). But if your shell is configured to charge the cwd before the code in your runCommand is executed, then the cwd may not be your home directory. However, all is not list. The environment variable HOME always contains the path to the home directory of the current user. So to guarantee that you get the home directory regardless of what the cwd happens to be, use the following:
runCommand('echo "$HOME"')
Iām puzzled about the replacement about the carriage return in your example. MacOS does not emit a carriage return at the end of lines, only a newline (this is true on all operating systems that are certified as UNIX or POSIX compliant). You can see this in the following obtained by piping the output of pwd
into hexdump
(try this on your own Mac). Note that the last character at the end of the hex is 0a
, which is a newline; it would be 0d
if it were a carriage return:
$ pwd | hexdump -C
00000000 2f 55 73 65 72 73 2f 72 6f 67 65 61 6c 65 78 0a |/Users/rogealex.|
00000010
Could it be that runCommand()
is itself adding the carriage return??
Did you try the demo file? If you use the stamp to get the cwd do you get something different? Also see this on the Command Line and Tinderbox. I can add some clarification to that article if needs be. I do think it fair though that if the user has gone to the lengths of setting a non-default HOME
on their system they will know enough to adjust the documentation available.
Argh, the article on runCommand() is confusing as I didnāt fully document this change in v6.0.1:
The runCommand() command has been extended to accept an optional third argument specifying the intended working directory.
runCommand(command,input,directory)
creates a shell and runs the designated command. The input, if any, is passed to the commandās standard input. If directory is specified, it sets the working directory. Otherwise, the working directory is the userās folder ~. (831)
That is what is behind the cryptic reference to a ādirectoryā option at the end of my runCommand article, which Iāll update IDC.
So, further to my demo file, if you need your command to run from a location other than HOME
you can do so via that third optional input for runCommand.
As to the line return, Iām not sure. It wasnāt until I got problems concatenating the home folder to the rest of the search path that I realised there was a line break. In resolving that, I discovered the gremlin was a carriage return \r
and not, as Iād initially guessed, a line break \n
. The latter matters when trying to remove that character!
Glad as I am that I can find where my doc is, I think it would be so much easier for the general user is action code had a property docPath
that returned the full POSIX path of the current TBX, and docName
as the names of the TBX file (plus extension). From that string itās easy to construct alternative path, get the doc name (sans extension), etc.
HTH!
Aha; runCommand is doing this in the services of a text engine we havenāt used in eons. I expect to change this in Tinderbox 9.
@mwra ā HOME
is set by the shell, and remains set unless the user explicitly changes it (Iāve never seen that done though I am sure there are use cases for do so). But is is not uncommon to have the shell switch to a different directory before turning control over to the user, and determining if this is the case is not predictable without opening one of the run control files (E.g., zsh.rc) and looking to see if that has been done. The real point is that you cannot in runCommand count on pwd
returning the userās home directory. Instead use the code that I suggested, which is guaranteed:
runCommand('echo "$HOME"')
Note that the double quotes around $HOME
are necessary (if you use single quotes instead, echo
would emit $HOME
as its result; zsh ā now the default shell in MacOS ā treats double and single quotes differently, as do most shells).
As for your first query, yes I get the same behavior as you. What spired my response what that in your post you stated that pwd
returns the userās home directory, which is technically not what it does. My objective was to add clarity to the conversation (the professor in me).
Finally, while you and I are comfortable with using runCommand
and perhaps the shell in general, my sense is that most users of Tinderbox are not (and would rather not be). Having Tinderbox provide a function to return the path to the currently open file would be authoritative and not require inference (or hope) that one has made the right decisions. I realize that each request that @MarkB acquiesces to comes at the expense of some other feature.
Amen. In another channel Iāve suggested action code properties docPath() and docTitle() with optional boolean POSIX-escaped options which might route around some of these issues. My demo above took more effort and thought than expected ājustā to get a path. Iām conscious thatās off-putting for a string people might need. Not necessarily often, but when in needā¦!
Iāve have just updated my aTbRef articles on the Command Line and runCommand(), to reflect errors mentioned up-thread.