"alias" does not work on windows

[Thorsten Kaufmann]

Hi there,

so alias causes an error message on windows for me ('doskey' is not recognized as an internal or external command,operable program or batch file.)

Both before resolve and after resolve the doskey command works in the shell though. Hence i am a bit at loss why. Is it just me or does it break for others too (in which case i'll make it a ticket and try to resolve it)

Cheers,

Thorsten

[yawpitch]

Not sure if this is the issue as it's a bit hard to track through Rez's calls to subprocess.Popen, but in modern versions of Windows "doskey" is a builtin command of CMD.exe and hence can only ever be accessed in a subprocess.Popen call that is invoked with shell=True.

M

[Thorsten Kaufmann]

What do you mean with "modern"? Currently on Win7 here. And doskey,exe is available in both system32 and SysWOW64 so i think this is not the case for me. I actually tried directly calling doskey via suprocess.call() without shell=True in commands() and that also works. So i need to dive a little deeper i guess. Using doskey may also be a way to work around the path variable issue. If i add the executables via doskey and dlls are next to the exe i should not need to extend PATH for many tools.

Cheers,

Thorsten

[Thorsten Kaufmann]

So i am getting closer, but still have no idea why. It breaks as soon as i add either an env.PATH.append or an env.PATH.prepend. This leads to the path being SET in the corresponding batch file just before doskey is executed.

I implemented appendenv and it still is called as setenv. Still have not found out why and where this happens.

Cheers,

Thorsten

[Thorsten Kaufmann]

More info: It seems it is the append that breaks things. when using env.PATH.append AND env.PATH.prepend the latter works, no matter if i implement prependenv or not, the former breaks.

If i implement prepend then that function is called (in cmd.py that is). If i do not implement it, then it still works and setenv is called with %PATH%

If i implement append it still calls setenv and setenv does not add %PATH% in this case and the PATH is cut short.

This is kind of compensated for by a latter path setting injecting most of the dropped path, hence it looks fine after resolve, but alias commands are called before.

Still trying to find where that distinction is NOT made heh.

Cheers,

Thorsten

[Thorsten Kaufmann]

So it is not really related to appendenv or prependenv implementations either.

It seems that i misinterpreted prepend and append alltogether. The values are prepended or appended within rez's packages only. The whole set of variables combined is then prepended to the original one.

Is that intended behaviour or a bug on windows? If it is intended it could be pointed out more prominently i think.

The problem is, that the first occurence causes a SET to happen and only then prepend/append works within the rez paths. Then after all as said and done, the original PATH is appended to the whole set of rez based paths.

but alias is called before that happens. Hence doskey is not found as it is not on PATH because PATH at that time only contains paths added by packages.

Cheers,

Thorsten

[Allan Johns]

Ah yes. I vaguely recall hitting this case before - it isn't specific to Windows.

Again this comes back to the improved control I want to add over envvar behavior in this regard. There should be the option to set a var to a specific value before package commands are interpreted.

You could do this anyway though, come to think of it. Why not just set PATH in, say, "platform" package's pre_commands()?

A

--
You received this message because you are subscribed to the Google Groups "rez-config" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rez-config+...@googlegroups.com.
To post to this group, send email to rez-c...@googlegroups.com.
Visit this group at https://groups.google.com/group/rez-config.
For more options, visit https://groups.google.com/d/optout.

[Thorsten Kaufmann]

That would work around most likely. I would like the default behaviour to be to not remove the original value at all during package evaluation when using append and prepend. It just seems counterintuitive.

And for different things it may yield very unpredictable results when using any shell commands during commands(). There may also be custom tools that are on PATH that are not found in these cases

during commands() evaluation.

I will look into adding it to patform as a workaround for now, but i will need to find out where the original PATH is stored to make things more fail save.

Cheers,

Thorsten

[Thorsten Kaufmann]

I take that back. While it works to preserve PATH during package evaluation it doubles PATH in the resolved shell as rez re-injects the original PATH after package resolving.

Cheers,

Thorsten

[Allan Johns]

On Thu, Jun 9, 2016 at 2:14 AM, Thorsten Kaufmann <insti...@gmail.com> wrote:

That would work around most likely. I would like the default behaviour to be to not remove the original value at all during package evaluation when using append and prepend. It just seems counterintuitive.

See https://github.com/nerdvegas/rez/wiki/Package-Commands#variable-appending-and-prepending.

[Thorsten Kaufmann]

Thanks! I will gladly help adding more flexibility there should you need/want any help with that!

Cheers,

Thorsten

[Andy Nicholas]

Just to add to the thread, I'm experiencing the same problem (I'm also on Windows). I also get the complaint about missing DosKey, but it goes away if I put the alias command in the pre_commands(). However, the alias operation doesn't seem to work, unless I'm doing it wrong, which is quite possible as I'm still getting up to speed with Rez.

So in package.py, I'm doing this:

def pre_commands():

    alias("run_xsi","xsi.bat")

def commands():

    env.PATH.append(r"C:\Program Files\Autodesk\Softimage 2015\Application\bin")

and then running this from Windows cmd.exe:

res-env softimage -- run_xsi

Which fails, complaining that it doesn't know what "run_xsi" is. If I do this though:

res-env softimage -- xsi.bat

It launches Softimage without any problems.

[Andy Nicholas]

Ah, just seen Allan's post on this thread:

 

https://groups.google.com/forum/#!topic/rez-config/2VjoYaVXalg

If I understand rightly, trying to launch a tool using an alias with res-env -- won't work by design.

That's fine. Just wanted to make sure I'm not doing anything wrong. 

[Thorsten Kaufmann]

Hey Andy, thanks for the feedback!

Putting it in pre-commands is not consistently fixing this issue. It works "by chance" in your setup. It works as long as no other package environment was resolved that manipulates PATH. The first package doing so overwrites it and hence doskey is not found. So if you have a package before the one using doskey that manipulates PATH in pre_commands it will still fail.

The reason we can't just gather REZ_PATH as then inject that at the end is that we may need PATH to be modified for any of the packages depending on each other to even work during resolve. And if we would just modify PATH then we have a hard time distincting between the changes done by rez and the original PATH. Is that about right?

What if we save the original PATH, manipulate only REZ_PATH and set PATH during every step of the resolve?

For me it seems rather important to have PATH intact during resolving as it may also break locally installed packages or software that is not being provided as a package but locally installed (like in this case windows tools).

In addition i am thinking about way to provide the alias command also with non-shell scenarios. I think that should be not too difficult.

I am currently a bit on hold as i am off for a week as we had our third son last Sunday :)

Cheers,

Thorsten

[Andy Nicholas]

Hi Thorsten,

Thanks for the reply.

Yep, having re-written this email several times already with potential solutions that I ended up figuring didn't work, I'm a bit stuck for ideas ;)

The only thing I can think of is that you would need a way to make calls to "standard" tools like doskey that use the original PATH. You would have to assume that these fundamentals won't change during the process so you can capture the path at the beginning of the resolve.

Cheers,

Andy

[Allan Johns]

Hey all,

I think I suggested this in an earlier similar thread, why not just do this in the platform package:

# in platform-windows package.py

def pre_commands():

    env.PATH = my_set_of_predefined_system_paths

Because platform is so low level, *and* you're using pre_commands, this will be executed before any other commands, and will set PATH to a standard set of system paths. Any commands following will append to this value, and execution of any tools such as doskey (if I have that right) will work.

Longer term I plan on adding more fine-grained control over how variables behave wrt set/append etc.

Let me know if this works,

A

[Andy Nicholas]

Hi Allan,

Okay, thanks for your suggestion. Will give it a go.

Cheers,
Andy

[Andy Nicholas]

Yep, that seemed to work fine, albeit on a very simple scenario. Will keep you posted if I notice any problems.

Thanks again,

A

[Thorsten Kaufmann]

The Problem is, that i do not know all the paths. I can include them one by one of course. I thought about simply adding the whole PATH variable there so all are covered, but that simply doubles the whole PATH variable in the resolved shell as rez itself re-appends it after the resolve. With the limitations on environment variables and also shell input and output length that kind of defeats my planned use of doskey/alias to reduce reliance on PATH extensions.

It will serve as a workaround though until we have a better way. This is just for reference.

Cheers,
Thorsten