Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: TUP_CWD invalid when Tupfile depth >= 2 #515

Open
usrlocalben opened this issue Jan 24, 2025 · 1 comment
Open

Windows: TUP_CWD invalid when Tupfile depth >= 2 #515

usrlocalben opened this issue Jan 24, 2025 · 1 comment

Comments

@usrlocalben
Copy link

TUP_CWD uses Unix / separator char on Windows. If a Tupfile is in the root, or one dir deep, it's OK because TUP_CWD is just e.g. ... However, if the Tupfile is two or more dirs deep, then it is e.g. ../.. and makes an invalid command exe.

Alternatively/Additionally it could be that the mixed separator should be OK, but there is a problemat the exec/system() call.

/Tuprules.tup

THE_ROOT=$(TUP_CWD)

/foo/bar/Tupfile

include_rules

: |> $(THE_ROOT)\wvenv\Scripts\python --help > %o |> help.txt
[ tup ] [0.110s] Executing Commands...
* 0) foo\bar: ../..\wvenv\Scripts\python --help > help.txt
'..' is not recognized as an internal or external command,
operable program or batch file.
 *** tup messages ***
 *** Command ID=1432 failed with return value 1
@usrlocalben
Copy link
Author

usrlocalben commented Jan 24, 2025

I dug a little deeper.
Reading the code, I see that pipe > causes it to use cmd.exe to evaluate the command. (I guess, it's unclear at a glance what's going on w/ run_in_bash)

If I modify my command to use an output argument (instead of stdout + pipe) it works OK.

I'm tempted to close, but it still seems like there's an issue here. The command abstraction is leaking impl. details depending on the pipe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant