obsidian-execute-code
obsidian-execute-code copied to clipboard
Typescript Not Working
With ts-node path set to /opt/homebrew/bin/ts-node
, I get this error:
With ts-node path set to /opt/homebrew/bin/npx ts-node
I get this error:
Also tried setting ts-node
as an argument
Also tried just ts-node
, and settings ts-node
as an argument under npx.
Everything works fine from the terminal. Any ideas?
Thanks for a brilliant plugin, I absolutely love this!
Running macOS
Hi! Sorry for the late response! I can help troubleshoot. When you say that everything works fine from the terminal, what are you entering into the terminal (i.e. are you entering ts-node
, or the full path)?
Thanks for looking into this!
Either way works, ts-node is on path
Thanks!
I think that the issue is that your node
binary is available on the path to your shell, but not available to Obsidian. Could you try running these commands in a bash
block, through the plugin? Like:
```bash
which node
which ts-node
which npx
```
How did you install Node? If homebrew, try running brew link --overwrite node
.
That does seem like the issue! Not sure how to remedy though.
Also tried relinking via brew unlink node && brew link node
, same outcome
Alright. I think that the easiest solution would be to create symlinks from /usr/local/bin/foo
to /opt/homebrew/bin/foo
for each foo of npx, ts-node, node, etc.
Still no dice 😬
If I set ts-node path to usr/local/bin/npx ts-node
or usr/local/bin/ts-node
in settings I get this error
But in terminal, it works
(Tried rebooting OS & Obsidian etc)
Sorry to burden you with this, once again I super appreciate the extension and the work you do! Even if we can't figure this one out, thanks again.
Oh dear :( That is unfortunate, sorry.
To tell the truth, it doesn't have to be /usr/local/bin
; just somewhere on your PATH
. If you re-run the which node
, which ts-node
, etc. blocks, does it show the correct filepath? If it's still foo not found
, could you run echo "$PATH"
in a bash
block and send that? (of course, feel free to censor any sensitive sections)
Thank you! I'm happy to help out :) Even if we can't figure it out, thank you for working with me to try and fix the problem. If it ends up being a problem that we can fix from the plugin, this has been super helpful for future users! Thanks :)
(From Terminal) (From Obsidian)
Oh! I'm surprised that cargo is on there; everything else seems very... bare, in the PATH
that Obsidian has.
Do you know if your zshrc is being ran?
What happens if you run whoami
and pwd
in a bash block?
Messed around and realized .zshenv
is being sourced but .zshrc
is not (for run-shell blocks). (My .zshenv
has pretty much nothing and my .zshrc
has a ton).
Added export PATH=/opt/homebrew/bin:$PATH
to .zshenv
and voila
However, run-ts blocks are still failing in the same manner:
With full file path specified in settings:
With just ts-node
or npx ts-node
as file path:
Additionally tested
There already were a few issues by people using the combination MaxOS + Homebrew. We don't have a general solution yet but we there seems to be a common problem.
Same problem here. Have a homebrew installed nvm. Solution would be great!
As of now, I'm not sure what to do with this issue. If you're willing to help debug, that would be great; I'm not that familiar with Macs, so it's really good to have someone to test. What I'd advise you do:
- Try to follow the steps in this issue and see if they help
- If not, retry the symlinking step, but link from
/usr/bin
instead of from/usr/local/bin
-- seems likePATH
doesn't contain/usr/local/bin
on MacOS?
Well, node and ts-node versions are controlled by nvm, so it might not be a good idea to set symlinks.
But i have another observation:
If i set brew and nvm init scripts in .zshenv (which for some unknow reason is loaded by obsidians shell, while the other zsh configs are not loaded) this will work within obsidian and give proper values:
``shell
node -v
which node
ts-node -v
which ts-node
``
Output:
18.12.0
/Users/xxx/.nvm/versions/node/v18.12.0/bin/node
v10.9.1
/Users/xxx/.nvm/versions/node/v18.12.0/bin/ts-node
BUT: It does not help with the problem, calling some typescript code in obsidian nevertheless results in
"env: node: No such file or directory"
ts-node
calls the same version of node which was used to run it. Now that which node
works, could you try node
for the path and /path/to/ts-node
for the first argument? e.g:
thanks for your support, but sorry, still not working.
If you need a quick fix, copy and paste the output of which node
into ts-node path followed by the output of which ts-node
. They both need to be in the ts-node path field and the arguments field should be left blank.
The problem is that the shell environment executing the provided commands isn't loading the local .zshrc
or .bashrc
. It also only includes bin, /usr/bin, and /usr/sbin. These folders are protected by MacOS and, by default, should not be written to even if it's just for the purpose of adding symlinks.
It would be much better if we could ensure that /usr/local/bin gets added to the shell environment before commands are executed.
The problem is that the shell environment executing the provided commands isn't loading the local .zshrc or .bashrc. It also only includes bin, /usr/bin, and /usr/sbin. These folders are protected by MacOS and, by default, should not be written to even if it's just for the purpose of adding symlinks.
@isr413 Do you know how we can make sure that the .*shrc files are loaded?
If you need a quick fix, copy and paste the output of
which node
into ts-node path followed by the output ofwhich ts-node
. They both need to be in the ts-node path field and the arguments field should be left blank.
You made my day! - For me a quick fix is fine. Btw.: I wasn't aware that the path field sets $PATH, i always thought it was the path the plugin calls directly, so i did not try it this way.
Thanks!
The path field doesn't set $PATH. I believe that this works because it directly calls npx ts-node
, without any indirection or dependence on the $PATH. This is a good quick-fix; thanks, @isr413!
@aidan-gibson pinging for a fix for your issue! :)
The problem is that the shell environment executing the provided commands isn't loading the local .zshrc or .bashrc. It also only includes bin, /usr/bin, and /usr/sbin. These folders are protected by MacOS and, by default, should not be written to even if it's just for the purpose of adding symlinks.
@isr413 Do you know how we can make sure that the .*shrc files are loaded?
https://unix.stackexchange.com/questions/71253/what-should-shouldnt-go-in-zshenv-zshrc-zlogin-zprofile-zlogout
Suggest everyone to read the top two answers to this StackExchange. But TL;DR:
.zshrc
is for interactive shells and is read once per shell creation
.zshenv
is for applications, etc and is read every time.
export your $PATH, $EDITOR, other application level vars here.
@skdamico I haven't looked through all of the code yet to see how the ts executor is being formed, but I assume that somewhere along the road, a child process is forked off that executes the provided commands. If that's correct, then the child process only has access to the environmental variables within the scope of the Obsidian process, which isn't much.
You would need to do one of two things. Either, you would need to source select rc, env, or profile files before executing the provided command or add additional directories to the path yourself. I would recommend the latter.
You would need an input field to accept additional directories, such as what the Shell Commands plugin uses https://publish.obsidian.md/shellcommands/Environments/Additions+to+the+PATH+environment+variable
You would need to concatenate those with the PATH variable and pass that into the child process, the child process would need the additional argument { env: dirs.join(":") + ":" + process.env.PATH }
. You would of course need to ensure that some dir is provided, otherwise, you wouldn't pass this argument at all.
This would at least allow users to specify which directories they want included in their PATH. For most UNIX users, adding /usr/local/bin would be enough but others may also want to include their homebrew dir, etc.