"cmd.exe /c echo '%ProgramFiles%' returned empty string

[dE_logics]

hi.

I'm trying to install a program using winetricks, but I'm using a separate wine install and WINEPREFIX, I run any command as such -

WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' ./winetricks

And it returns -

/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32 cmd.exe /c echo '%ProgramFiles%' returned empty string

Also in the winetricks wiki it has not been explained properly how to point out to a seperate wine install.

I tried exporting all the WINE, WINEPREFIX and WINEARCH variables, but it doesn't workout.

On the other hand -

WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' '/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin/wine' cmd

C:\>echo %ProgramFiles%
C:\Program Files

C:\>

[dimesio]

So this is what you're telling winetricks:

'/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32'

And this is what you use when you run cmd.exe directly:

'/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin/wine

See the difference?

[dE_logics]

I tried that, it doesn't matter -


WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin/wine' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' ./winetricks
------------------------------------------------------
/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin/wine cmd.exe /c echo '%ProgramFiles%' returned empty string
------------------------------------------------------

Code: Select all

cd '/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin'
de@OLD_BROKEN_LAP ~/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32
/wine-1.3.32/bin $ ls
function_grep.pl  regsvr32        wineboot     winecpp   wineg++    winepath
msiexec           widl            winebuild    winedbg   winegcc    wineserver
notepad           wine            winecfg      winedump  winemaker  wmc
regedit           wine-preloader  wineconsole  winefile  winemine   wrc

[dE_logics]

Also -

WINEPREFIX=/home/de/media_writeit\!/temp\(others\)/walkthrough/ /home/de/media_writeit\!/FOSS/additional\ packages/Wine\ prefixes/Works\ with\ wine\ 1.3.32/wine-1.3.32/bin/wine cmd.exe /c echo '%ProgramFiles%'

C:\Program Files

[dimesio]

What happens if you leave off the ./ in front of winetricks?

Code: Select all

WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32/bin/wine' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' winetricks 

[dE_logics]

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

However -

WINEPREFIX='/home/de/game/temp(game)/soundforge-10' ./winetricks
------------------------------------------------------
wine cmd.exe /c echo '%ProgramFiles%' returned empty string

[dimesio]

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

How did you get winetricks? I've never used ./ in front of it, and it executes just fine for me.

[DanKegel]

WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' ./winetricks

returns

/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32 cmd.exe /c echo '%ProgramFiles%' returned empty string

I seem to recall hearing that the "returned empty string" symptom happens when running 32 bit wine on a 64 bit system, and was caused by a missing wine.inf entry for wow64.
Or something like that. I haven't had time to investigate since I heard that.

Also in the winetricks wiki it has not been explained properly how to point out to a seperate wine install.

I tried exporting all the WINE, WINEPREFIX and WINEARCH variables, but it doesn't workout.

WINE is how you tell winetricks which wine to run.

WINEPREFIX is how you tell wine (and winetricks) where the fake C drive and
registry live.

Do you really have two versions of wine? What program are you trying to install?

(Dimesio: The ./ in front of winetricks is for when you've downloaded winetricks yourself
and not installed it, but have marked it executable.
If you haven't marked it executable, you have to use 'sh winetricks'.
If you use the winetricks installed by your distro, you don't want the ./ or the sh.
This is all about how the shell searches for commands in the directories
listed in the PATH environment variable.)

[dE_logics]

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

How did you get winetricks? I've never used ./ in front of it, and it executes just fine for me.

I've downloaded winetricks. winetricks is a bash script, so it can be placed anywhere. The '.' in the './' represents the current location, thus ./winetricks asks bash to execute the winetricks script which's in the current directory.

WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' ./winetricks

returns

/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32 cmd.exe /c echo '%ProgramFiles%' returned empty string

I seem to recall hearing that the "returned empty string" symptom happens when running 32 bit wine on a 64 bit system, and was caused by a missing wine.inf entry for wow64.
Or something like that. I haven't had time to investigate since I heard that.

Also in the winetricks wiki it has not been explained properly how to point out to a seperate wine install.

I tried exporting all the WINE, WINEPREFIX and WINEARCH variables, but it doesn't workout.

WINE is how you tell winetricks which wine to run.

WINEPREFIX is how you tell wine (and winetricks) where the fake C drive and
registry live.

Do you really have two versions of wine? What program are you trying to install?

Yes, this system is 64 bit and this problem exists when you try running a 64 bit wine prefix on a 32 bit wine installation. But in my case, every prefix is 32bit.

This time around, since the WINE variable doesn't appear to be working, I had to drop it and use the prefix of wine-1.3.32 (static build) with wine-1.3.29 (system install). I installed a few packages using winetricks, after which it suddenly stopped working and started giving this error.

Later on (now) I noticed that some wine processes where still running in background which were causing this problem.

However, the main issue now is, the WINE variable doesn't appear to be working.

I'm trying to make soundforge 10 work. Currently there analyzer graph is bank.

[Martin Gregorie]

On Thu, 2011-11-10 at 22:35 -0600, dimesio wrote:

dE_logics wrote:

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

How did you get winetricks? I've never used ./ in front of it, and it executes just fine for me.

Some distros (the RedHat ones and probably others) don't include '.' or
$HOME in $PATH by default. The first thing I do when I set up a new
login users is to make sure '.', $HOME and $HOME/bin are added to $PATH,
preferably at the right end. Its such an automatic action that its easy
to forget you did it years ago.

To dE_logics:

It sounds like your $HOME directory isn't in your search path. Post the
output from this:

<code>
echo $PATH
</code>

So we can see what your search path looks like.


Martin

[Usurp]

On Thu, 2011-11-10 at 22:35 -0600, dimesio wrote:

dE_logics wrote:

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

How did you get winetricks? I've never used ./ in front of it, and it executes just fine for me.

Some distros (the RedHat ones and probably others) don't include '.' or
$HOME in $PATH by default. The first thing I do when I set up a new
login users is to make sure '.', $HOME and $HOME/bin are added to $PATH,
preferably at the right end. Its such an automatic action that its easy
to forget you did it years ago.

To dE_logics:

It sounds like your $HOME directory isn't in your search path. Post the
output from this:

<code>
echo $PATH
</code>

So we can see what your search path looks like.


Martin

Having '.' and $HOME in $PATH can lead to subtle failures,
if you create a file that has the same name as an existing command.

Simple example: the updatedb command from mlocate

[Martin Gregorie]

On Fri, 2011-11-11 at 07:33 -0600, Usurp wrote:

Having '.' and $HOME in $PATH can lead to subtle failures,
if you create a file that has the same name as an existing command.

Simple example: the updatedb command from mlocate

That is why, if you're wise, you always run 'which' to check check
whether the script/program name you just thought up is going to clash
with anything else. Its also why I said "add them to the right hand
end", as in:

export PATH="$PATH:$HOME/bin:."

$PATH is searched left to right, so doing it this way guarantees that
pre-existing stuff takes precedence over anything you wrote without
first checking for name clashes.

Martin

[perryh]

"Usurp" <[email protected]> wrote:

Having '.' and $HOME in $PATH can lead to subtle failures,
if you create a file that has the same name as an existing command.

Only if you give the created file the "executable" permission, or if
you use the "." or "source" shell builtin in a manner that causes it
to search the path.

[dE_logics]

On Thu, 2011-11-10 at 22:35 -0600, dimesio wrote:

dE_logics wrote:

Nothing will happen (and nothing happened), winetricks is only available in the current directory, so it says command not found.

How did you get winetricks? I've never used ./ in front of it, and it executes just fine for me.

Some distros (the RedHat ones and probably others) don't include '.' or
$HOME in $PATH by default. The first thing I do when I set up a new
login users is to make sure '.', $HOME and $HOME/bin are added to $PATH,
preferably at the right end. Its such an automatic action that its easy
to forget you did it years ago.

To dE_logics:

It sounds like your $HOME directory isn't in your search path. Post the
output from this:

<code>
echo $PATH
</code>

So we can see what your search path looks like.


Martin

I've not seen any distro which sets '.' in it's PATH.

Also why will I need $HOME in $PATH?

PATH for user is -
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.5.3:/usr/games/bin

Also '.' in $HOME doesn't make sense.

On Fri, 2011-11-11 at 07:33 -0600, Usurp wrote:

Having '.' and $HOME in $PATH can lead to subtle failures,
if you create a file that has the same name as an existing command.

Simple example: the updatedb command from mlocate

That is why, if you're wise, you always run 'which' to check check
whether the script/program name you just thought up is going to clash
with anything else. Its also why I said "add them to the right hand
end", as in:

export PATH="$PATH:$HOME/bin:."

$PATH is searched left to right, so doing it this way guarantees that
pre-existing stuff takes precedence over anything you wrote without
first checking for name clashes.

Martin

I didn't know that presidency part, thanks.

[Martin Gregorie]

On Sat, 2011-11-12 at 06:46 -0600, dE_logics wrote:

I've not seen any distro which sets '.' in it's PATH.

Fair enough. I'm an active developer and find it convenient to include
'.' in my search path because then I know that any script or program
that I write can always be executed by using a name that is relative to
me current directory.

Also why will I need $HOME in $PATH?

I suggested adding $HOME/bin to your search path, not $HOME.

If you write small shell scripts, e.g. as wrappers for Wine applications
or as a short-hand for common actions and they are intended to only be
used from one login, then a convenient place to keep them is in a
$HOME/bin directory because this keeps clutter out of your login
directory. If you do this you'll want to include $HOME/bin in the search
path for that login by editing .bash_profile

If such scripts are for more general use they should be put in
"/usr/local/bin" and any associated configuration files should be in
"/usr/local/etc". Make sure that the "/usr/local" structure is backed up
along with "/home".

You should reserve "/bin" and "/usr/bin" for programs and scripts that
are part of your distro. Apart from anything else, if you upgrade your
distro or do a clean install you may loose anything you put in those
directories while, if you backed up the contents of /usr/local then its
easy to drop it back in place after the upgrade or install.


Martin

[Frédéric Delanoy]

On Thu, Nov 10, 2011 at 11:16, dE_logics <[email protected]> wrote:

hi.

I'm trying to install a program using winetricks, but I'm using a separate wine install and WINEPREFIX, I run any command as such -

WINEARCH="win32" WINE='/home/de/media_writeit!/FOSS/additional packages/Wine prefixes/Works with wine 1.3.32/wine-1.3.32' WINEPREFIX='/home/de/media_writeit!/temp(others)/walkthrough' ./winetricks

Cmd command-line arguments parsing has some issues. You should avoid
using special characters like '(', ')' or '!' in your paths (probably
also holds for many other programs TBH)

Frédéric

[DanKegel]

I think you're using WINE wrong.
It needs to point to the wine binary, not the directory that contains it.

e.g. I often do

export WINE=$HOME/wine-git/wine

[DanKegel]

I just updated http://winetricks.googlecode.com/svn/tr ... winetricks
to complain if WINE is set wrong.