Script to run Wine and save log

[Gert van den Berg]

Hi all,

I created as little script to run wine and automatically log the
output and some basic information to a file.

It can be downloaded from here: http://www.mohag.net/wine_with_log

How to use:
1. Download (or create) it somewhere and set it executable.
wget http://www.mohag.net/wine_with_log
chmod +x wine_with_log

2. Run application with wine_with_log rather than wine
3. Logs can be found in the wine-logs subdirectory (Filenames:
<command>.<date>.<wine version>.log)

It attempts to run wine-git from ~/wine-git/wine first, followed by
wine from /usr/local, then wine from /usr and finally the default wine
(no path specified).

It adds some general information about the environment that it is used
in at the top of the log. Please check this information before
uploading / publishing the log publicly to ensure that it contains no
private information.

Please let me know of any bugs. Other improvements are welcome.

TODO:
1. Distro detection with lsb_release if available.
2. Ability to dump more info about Wine configurion within the
WINEPREFIX, e.g. Windows version, etc.
3. <Your suggestion here>

Gert

Example log:
----------------------------------------------------------
Wine version: wine-1.1.24-141-g4156b6a
WINEPREFIX: '/home/mohag/.wine'
WINEPREFIX state: 'Clean'
Working directory: '/home/mohag/Downloads'
Date: Wed Jun 24 21:28:05 SAST 2009
OS info (uname -a): 'Linux mohagpc 2.6.28-13-generic #44-Ubuntu SMP
Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux'
Command: '/home/mohag/wine-git/wine winecfg'
----------------------------------------------------------
wine: created the configuration directory '/home/mohag/.wine'
fixme:mixer:ALSA_MixerInit No master control found on USB Device
0x46d:0x89d, disabling mixer
fixme:system:SetProcessDPIAware stub!
fixme:dwmapi:DwmIsCompositionEnabled 0x33cf94
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
fixme:advapi:SetNamedSecurityInfoW
L"C:\\windows\\gecko\\0.9.1\\wine_gecko\\components\\xpti.dat" 1
536870916 (nil) (nil) 0x33c960 (nil)
fixme:iphlpapi:NotifyAddrChange (Handle 0x60ae908, overlapped 0x60ae910): stub
fixme:file:MoveFileWithProgressW MOVEFILE_WRITE_THROUGH unimplemented
fixme:advapi:SetNamedSecurityInfoW
L"C:\\windows\\gecko\\0.9.1\\wine_gecko\\components\\compreg.dat" 1
536870916 (nil) (nil) 0x33ca50 (nil)
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\xpcom.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\softokn3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\nssutil3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\nss3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\plugins\npnul32.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\xul.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\nspr4.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\sqlite3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\ssl3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\plc4.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\smime3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\nssdbm3.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\js3250.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\nssckbi.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\plds4.dll")
- Symbol NSGetModule not found
0[19eba8]: nsNativeModuleLoader::LoadModule("C:\windows\gecko\0.9.1\wine_gecko\freebl3.dll")
- Symbol NSGetModule not found
fixmeDllCanUnloadNow stub
wine: configuration in '/home/mohag/.wine' has been updated.
fixme:mixer:ALSA_MixerInit No master control found on USB Device
0x46d:0x89d, disabling mixer
----------------------------------------------------------

Script code: (if wget is impracticable for some reason)
#!/bin/sh
# wine_with_log: Script for running wine while showing and logging output
# Gert van den Berg, 24 June 2009
# This script is released into the public domain
#
# The script prefers a wine-git in the home directory, followed by a
wine in /usr/local
# and /usr, with the system's default wine version being tried last

logpath="$HOME/wine-logs"

if [ -x "$HOME/wine-git/wine" ]; then
wine="$HOME/wine-git/wine"
elif [ -x /usr/local/bin/wine ]; then
wine="/usr/local/bin/wine"
elif [ -x /usr/bin/wine ]; then
wine="/usr/bin/wine"
else
wine=wine
fi

WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" export state not changed
date=`date +%Y%m%d-%H:%M:%S`

if [ -d "$WINEPREFIX" ]; then
wineprefixstatus="Not clean"
else
wineprefixstatus="Clean"
fi

if ! winever=`$wine --version` 2> /dev/null; then
echo "Fatal error: Cannot run wine with command '$wine'!" 1>&2
exit 1
fi

mkdir "$logpath"

logname="$logpath/$1.$date.$winever.log"

echo "----------------------------------------------------------"|tee "$logname"
echo "Wine version: $winever" |tee -a "$logname"
echo "WINEPREFIX: '$WINEPREFIX'"|tee -a "$logname"
echo "WINEPREFIX state: '$wineprefixstatus'"|tee -a "$logname"
echo "Working directory: '`pwd`'"|tee -a "$logname"
echo "Date: `date`"|tee -a "$logname"
echo "OS info (uname -a): '`uname -a`'"|tee -a "$logname"
echo "Command: '$wine $@'"|tee -a "$logname"
echo "----------------------------------------------------------"|tee
-a "$logname"
wine "$@" 2>&1|tee -a "$logname"
echo "----------------------------------------------------------"|tee
-a "$logname"

[MoHaG]

Little bugfix:

Code: Select all

wine "$@" 2>&1|tee -a "$logname"

should be

Code: Select all

"$wine" "$@" 2>&1|tee -a "$logname"

The version on my site has been corrected.

[austin987]

On Wed, Jun 24, 2009 at 2:38 PM, Gert van den Berg<[email protected]> wrote:

Hi all,

I created as little script to run wine and automatically log the
output and some basic information to a file.

It can be downloaded from here: http://www.mohag.net/wine_with_log

How to use:
1. Download (or create) it somewhere and set it executable.
wget http://www.mohag.net/wine_with_log
chmod +x wine_with_log

2. Run application with wine_with_log rather than wine
3. Logs can be found in the wine-logs subdirectory (Filenames:
<command>.<date>.<wine version>.log)

It attempts to run wine-git from ~/wine-git/wine first, followed by
wine from /usr/local, then wine from /usr and finally the default wine
(no path specified).

It adds some general information about the environment that it is used
in at the top of the log. Please check this information before
uploading / publishing the log publicly to ensure that it contains no
private information.

Please let me know of any bugs. Other improvements are welcome.

TODO:
1. Distro detection with lsb_release if available.

Not all distro's use lsb_release. /etc/release, /etc/issue,
/etc/redhat-release, etc. are other popular ways to get that info.
Keep in mind, not everyone uses Linux . `uname -s` will give you
the OS type (in a portable way).

Script code: (if wget is impracticable for some reason)
#!/bin/sh
# wine_with_log: Script for running wine while showing and logging output
# Gert van den Berg, 24 June 2009
# This script is released into the public domain
#
# The script prefers a wine-git in the home directory, followed by a
wine in /usr/local
# and /usr, with the system's default wine version being tried last

logpath="$HOME/wine-logs"

if [ -x "$HOME/wine-git/wine" ]; then
       wine="$HOME/wine-git/wine"
elif [ -x /usr/local/bin/wine ]; then
       wine="/usr/local/bin/wine"
elif [ -x /usr/bin/wine ]; then
       wine="/usr/bin/wine"
else
       wine=wine
fi

It'd be better to take WINE as an environmental variable first, that
way the user can specify which they want. E.g., I keep 'vanilla' wine
installed in /usr/local/bin, but when testing, may run from
$HOME/wine-git. Many users have custom versions in random places. You
should use wine="`which wine`" as a fallback.

WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" export state not changed

Not sure what you're trying to do with the 'export ...'. Was that
meant to a comment? Output to the log?

date=`date +%Y%m%d-%H:%M:%S`

if [ -d "$WINEPREFIX" ]; then
       wineprefixstatus="Not clean"
else
       wineprefixstatus="Clean"
fi

the '[ ] ; then' isn't portable (just found this out myself ). Put
the 'then' on a separate line, remove the ';'.

if ! winever=`$wine --version` 2> /dev/null; then
       echo "Fatal error: Cannot run wine with command '$wine'!" 1>&2
       exit 1

Move this up earlier with the wine check.

mkdir "$logpath"

logname="$logpath/$1.$date.$winever.log"

echo "----------------------------------------------------------"|tee "$logname"
echo "Wine version: $winever" |tee -a "$logname"
echo "WINEPREFIX: '$WINEPREFIX'"|tee -a "$logname"
echo "WINEPREFIX state: '$wineprefixstatus'"|tee -a "$logname"
echo "Working directory: '`pwd`'"|tee -a "$logname"
echo "Date: `date`"|tee -a "$logname"
echo "OS info (uname -a): '`uname -a`'"|tee -a "$logname"
echo "Command: '$wine $@'"|tee -a "$logname"
echo "----------------------------------------------------------"|tee
-a "$logname"
wine "$@" 2>&1|tee -a "$logname"

Should be $wine

--
-Austin

[Gert van den Berg]

On Wed, Jun 24, 2009 at 21:52, Austin English<[email protected]> wrote:

On Wed, Jun 24, 2009 at 2:38 PM, Gert van den Berg<[email protected]> wrote:

TODO:
1. Distro detection with lsb_release if available.

Not all distro's use lsb_release. /etc/release, /etc/issue,
/etc/redhat-release, etc. are other popular ways to get that info.
Keep in mind, not everyone uses Linux . `uname -s` will give you
the OS type (in a portable way).

There is a uname -a further down.

lsb_release works nice for identifying the Linux distro, *if* it is
present... (And for now at least, uname should be suffiecient on
non-Linux anyway, except maybe with some OpenSolaris distributions...)

It'd be better to take WINE as an environmental variable first, that
way the user can specify which they want. E.g., I keep 'vanilla' wine
installed in /usr/local/bin, but when testing, may run from
$HOME/wine-git. Many users have custom versions in random places. You
should use wine="`which wine`" as a fallback.

Fixed with an ugly hack....

WINEPREFIX="${WINEPREFIX:-$HOME/.wine}" export state not changed

Not sure what you're trying to do with the 'export ...'. Was that
meant to a comment? Output to the log?

Should have been comment...

date=`date +%Y%m%d-%H:%M:%S`

if [ -d "$WINEPREFIX" ]; then
       wineprefixstatus="Not clean"
else
       wineprefixstatus="Clean"
fi

the '[ ] ; then' isn't portable (just found this out myself ). Put
the 'then' on a separate line, remove the ';'.

"Why I normally use Perl "

(I *know* it works under bash on Solaris, I usually don't bother with
plain Bourne...)

if ! winever=`$wine --version` 2> /dev/null; then
       echo "Fatal error: Cannot run wine with command '$wine'!" 1>&2
       exit 1

Move this up earlier with the wine check.

Done

Should be $wine

Fixed

Thanks, I could probably do with a more elegant implementation of
setting the wine variable than the "set it, overwrite it
afterwards"-method.. (It should probably default to `which wine` and
only change if a variable is set ($WINE currently).)

Uploaded new version. (I would probably need to do some kind of
version control eventually and actually add version numbers...)

Added some of PleegWat's off-list suggestions as well.

Somethings that would be nice to add (preferably with a proper option parser):
Graphics card model / driver detection (Portability might be hard....)
State of common problematic processes, such as pulseaudio / compiz
Logged in user (`id` should work..)

(I should probably test it on my MacBook and the OpenSolaris box that
I'm planning to install soon...)

Gert

Code:
#!/bin/sh
# wine_with_log: Script for running wine while showing and logging output
# Gert van den Berg, 24 June 2009
# This script is released into the public domain
#
# The script prefers a wine-git in the home directory, followed by a
wine in /usr/local
# and /usr, with the system's default wine version being tried last

logpath="$HOME/wine-logs"

if [ -x "$HOME/wine-git/wine" ]
then
wine="$HOME/wine-git/wine"
elif [ -x /usr/local/bin/wine ]
then
wine="/usr/local/bin/wine"
elif [ -x /usr/bin/wine ]
then
wine="/usr/bin/wine"
else
wine="`which wine`"
fi

# If WINE is defined, we override $wine
wine="${WINE:-$wine}"

# Get Wine version number
if ! winever="`$wine --version`" 2> /dev/null; then
echo "Fatal error: Cannot run wine with command '$wine'!" 1>&2
exit 1
fi

# We don't export WINPREFIX, in case the dault change, but assume a
default of ~/.wine
WINEPREFIX="${WINEPREFIX:-$HOME/.wine}"
date="`date +%Y%m%d-%H:%M:%S`"

if [ -d "$WINEPREFIX" ]
then
wineprefixstatus="Pre-existing"
else
wineprefixstatus="Clean"
fi

if ! ( [ -d "$logpath" ] || mkdir "$logpath" 2> /dev/null )
then
echo "Fatal Error: Cannot create / find log path '$logpath'" 1>&2
exit 2
fi

logname="$logpath/$1.$date.$winever.log"

( # indentation broken to ensure correct log header output
echo "----------------------------------------------------------
Wine version: $winever
WINEPREFIX: '$WINEPREFIX'
WINEPREFIX state: '$wineprefixstatus'
Working directory: '`pwd`'
Date: `date`
OS info (uname -a): '`uname -a`'
Command: '$wine $@'
----------------------------------------------------------"
"$wine" "$@" 2>&1
echo "----------------------------------------------------------"
) |tee -a "$logname"

[austin987]

On Wed, Jun 24, 2009 at 4:30 PM, Gert van den Berg<[email protected]> wrote:

On Wed, Jun 24, 2009 at 21:52, Austin English<[email protected]> wrote:

On Wed, Jun 24, 2009 at 2:38 PM, Gert van den Berg<[email protected]> wrote:

TODO:
1. Distro detection with lsb_release if available.

Not all distro's use lsb_release. /etc/release, /etc/issue,
/etc/redhat-release, etc. are other popular ways to get that info.
Keep in mind, not everyone uses Linux . `uname -s` will give you
the OS type (in a portable way).

There is a uname -a further down.

lsb_release works nice for identifying the Linux distro, *if* it is
present... (And for now at least, uname should be suffiecient on
non-Linux anyway, except maybe with some OpenSolaris distributions...)

uname is portable, and should work everywhere. What's *not* portable,
is, e.g., grepping uname for answers, e.g.,:
`uname -a` | grep Linux
Yes, I've seen this done. But what happens if you're on a *BSD box
with the hostname 'Linux_sucks'.

I meant if you want to do OS specific code paths, use uname -s.

date=`date +%Y%m%d-%H:%M:%S`

if [ -d "$WINEPREFIX" ]; then
       wineprefixstatus="Not clean"
else
       wineprefixstatus="Clean"
fi

the '[ ] ; then' isn't portable (just found this out myself ). Put
the 'then' on a separate line, remove the ';'.

"Why I normally use Perl "

(I *know* it works under bash on Solaris, I usually don't bother with
plain Bourne...)

Right. I'm not sure where it doesn't work (I'm told Solaris, but
haven't tested). But never hurts to be safe.

Somethings that would be nice to add (preferably with a proper option parser):
Graphics card model / driver detection (Portability might be hard....)

Not sure how easy that is, tbh.

State of common problematic processes, such as pulseaudio / compiz

Yes, good idea. Preferably with a warning/error if they're enabled.

Logged in user (`id` should work..)

`id` gives a lot more info, e.g., groups a user is in. `whoami` would
be better. Or $USER.

(I should probably test it on my MacBook and the OpenSolaris box that
I'm planning to install soon...)

Good good.

--
-Austin

[Gert van den Berg]

On Wed, Jun 24, 2009 at 23:38, Austin English<[email protected]> wrote:

uname is portable, and should work everywhere. What's *not* portable,
is, e.g., grepping uname for answers, e.g.,:
`uname -a` | grep Linux
Yes, I've seen this done. But what happens if you're on a *BSD box
with the hostname 'Linux_sucks'.

I meant if you want to do OS specific code paths, use uname -s.

I'll try to avoid it in this script....

lsb_release is one of those handy programs that is never installed on
a box when you need it...

(I *know* it works under bash on Solaris, I usually don't bother with
plain Bourne...)

Right. I'm not sure where it doesn't work (I'm told Solaris, but
haven't tested). But never hurts to be safe.

Normal Bourne is full of #$^#, and every vendor's version seem to have
its own quirks... And some replace it with another mostly-compatible
shell, like HP-UX's POSIX shell.

Somethings that would be nice to add (preferably with a proper option parser):
Graphics card model / driver detection (Portability might be hard....)

Not sure how easy that is, tbh.

Hmm...

Even a
card=`lspci | grep 'VGA ' 2> /dev/null`
card=${card:-Unknown}

might be better than nothing... (But it is UGLY and would probably
only work on Linux (that's what the /dev/null is for...))

State of common problematic processes, such as pulseaudio / compiz

Yes, good idea. Preferably with a warning/error if they're enabled.

I don't like grepping ps output though... There must be a better way to check...

Logged in user (`id` should work..)

`id` gives a lot more info, e.g., groups a user is in. `whoami` would
be better. Or $USER.

whoami doesn't work on Solaris. "who am i" does work though. id with
certain parameters can emulate whoami. (see "whoami --help")

I thought the group info might be useful for troubleshooting...

(I should probably test it on my MacBook and the OpenSolaris box that
I'm planning to install soon...)

Good good.

The MacBook is still on Tiger and the OpenSolaris box would be at
work, which should mean occasional testing, rather than a full test
before each release.

[austin987]

On Wed, Jun 24, 2009 at 5:05 PM, Gert van den Berg<[email protected]> wrote:

On Wed, Jun 24, 2009 at 23:38, Austin English<[email protected]> wrote:

Somethings that would be nice to add (preferably with a proper option parser):
Graphics card model / driver detection (Portability might be hard....)

Not sure how easy that is, tbh.

Hmm...

Even a
card=`lspci | grep 'VGA ' 2> /dev/null`
card=${card:-Unknown}

might be better than nothing... (But it is UGLY and would probably
only work on Linux (that's what the /dev/null is for...))

Right.

State of common problematic processes, such as pulseaudio / compiz

Yes, good idea. Preferably with a warning/error if they're enabled.

I don't like grepping ps output though... There must be a better way to check...

Personally, I'd just do:
if [ -x `which compiz` ]
then
echo "You've got comipz installed. This is bad, and conflicts with
Wine. Remove it."
fi

Logged in user (`id` should work..)

`id` gives a lot more info, e.g., groups a user is in. `whoami` would
be better. Or $USER.

whoami doesn't work on Solaris. "who am i" does work though. id with
certain parameters can emulate whoami. (see "whoami --help")

What's wrong with $USER? What exactly do you need this for, anyway?

I thought the group info might be useful for troubleshooting...

Not particularly. The only time that I can think of is for distro's
that make the video/audio devices owned by a video/audio group, and
don't automatically add regular users to that group.

--
-Austin

[Martin Gregorie]

On Wed, 2009-06-24 at 16:38 -0500, Austin English wrote:

uname is portable, and should work everywhere. What's *not* portable,
is, e.g., grepping uname for answers, e.g.,:
`uname -a` | grep Linux
Yes, I've seen this done. But what happens if you're on a *BSD box
with the hostname 'Linux_sucks'.

I think this is portable:

uname -a |grep -i "^linux"

Another thought: how portable is this?

if [ -f /proc/version ]
then
grep -i "^linux" </proc/version
fi

AFAIK it should work in all Linuxes with kernel 2.6.

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.


Martin

[austin987]

On Wed, Jun 24, 2009 at 5:18 PM, Martin Gregorie<[email protected]> wrote:

On Wed, 2009-06-24 at 16:38 -0500, Austin English wrote:

uname is portable, and should work everywhere. What's *not* portable,
is, e.g., grepping uname for answers, e.g.,:
`uname -a` | grep Linux
Yes, I've seen this done. But what happens if you're on a *BSD box
with the hostname 'Linux_sucks'.

I think this is portable:

       uname -a |grep -i "^linux"

Will break like I said above...just use:
if [ "`uname -s`" = Linux ]
then
....
fi

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.

Right.

--
-Austin

[Gert van den Berg]

On Thu, Jun 25, 2009 at 00:18, Martin Gregorie<[email protected]> wrote:

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.

All SUS-complaint unixes have a /bin/sh. Which might be a Bourne shell
(e.g. Solaris), POSIX shell (HP-UX), link to ash / dash / bash
(Various Linux / BSD version).... It ussualy run Bourne-scripts, but
might support various extensions which may not work in other shells.

[Martin Gregorie]

On Sat, 2009-06-27 at 09:16 +0200, Gert van den Berg wrote:

On Thu, Jun 25, 2009 at 00:18, Martin Gregorie<[email protected]> wrote:

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.

All SUS-complaint unixes have a /bin/sh. Which might be a Bourne shell
(e.g. Solaris), POSIX shell (HP-UX), link to ash / dash / bash
(Various Linux / BSD version).... It ussualy run Bourne-scripts, but
might support various extensions which may not work in other shells.

Another point I should have mentioned: I've used Unix installations
where the default shell was ksh, which is another good reason for
starting the script with "#!/bin/sh".

I take your point about non-standard extensions, but the way round that
is to stick to the original Bourne shell syntax and not use the
extensions.


Martin

[Gert van den Berg]

On Thu, Jun 25, 2009 at 00:10, Austin English<[email protected]> wrote:

Personally, I'd just do:
if [ -x `which compiz` ]
then
   echo "You've got comipz installed. This is bad, and conflicts with
Wine. Remove it."
fi

The problem is that compiz might be installed and not running, or that
a recent kwin / metacity / <insert name of xfce4 windows manager here>
with compositing enabled might be used.

See: http://en.wikipedia.org/wiki/Compositin ... w_managers
for a list

The only really effective method would be a way to query the current
Windows manager to see if it supports compositing. If anyone know of a
scriptable way to do this please let me know.

What's wrong with $USER? What exactly do you need this for, anyway?

I don't trust environment variables that can be set by the user. (I
know that $USER is not always defined, based on a script (bash of a
.bashrc on Solaris rather) I have that sets the terminal title to
$USER@`hostname` - ip (It works fine 90% of the time, but break with
certain methods of changing user ('su -' IIRC)))

Mainly to see whether the user is running as root.

I thought the group info might be useful for troubleshooting...

Not particularly. The only time that I can think of is for distro's
that make the video/audio devices owned by a video/audio group, and
don't automatically add regular users to that group.

True. And that would be detectable by "Does your audio work in other
program? / Does glxgears run?"

Anyone with suggestion for detecting a running pulseaudio / esd? (ps
is not a nice option due to some versions accepting only BSD / Sys-V
style arguments)

A new version is attached, mainly adding some graphics card info,
fixing $WINE behaviour. Uploaded to http://www.mohag.net/wine_with_log

Gert

New version:
#!/bin/sh
# wine_with_log: Script for running wine while showing and logging output
# Gert van den Berg, June 2009
# This script is released into the public domain
#
# The script prefers a wine specified in WINE, wine-git in the home directory
# with the system's default wine version being tried if the other versions
# can not be found

logpath="$HOME/wine-logs"

# try WINE env var
if [ -x "`which \"$WINE\"`" ] > /dev/null # suppress printing of path
then
wine="`which \"$WINE\"`"
# try wine-git in $HOME
elif [ -x "$HOME/wine-git/wine" ]
then
wine="$HOME/wine-git/wine"
# Try default Wine
else
wine="`which wine`"
fi

# Get Wine version number and check for wine's existance
if ! winever="`\"$wine\" --version`" 2> /dev/null; then
echo "Fatal error: Cannot run wine with command '$wine'!" 1>&2
exit 1
fi

# We don't export WINPREFIX, in case the dault change, but assume a
default of ~/.wine
WINEPREFIX="${WINEPREFIX:-$HOME/.wine}"
date="`date +%Y%m%d-%H:%M:%S`"

if [ -d "$WINEPREFIX" ]
then
wineprefixstatus="Pre-existing"
else
wineprefixstatus="Clean"
fi

if ! ( [ -d "$logpath" ] || mkdir "$logpath" 2> /dev/null )
then
echo "Fatal Error: Cannot create / find log path '$logpath'" 1>&2
exit 2
fi

BasicInfo="----------------------------------------------------------
Wine version: $winever
WINEPREFIX: '$WINEPREFIX'
WINEPREFIX state: $wineprefixstatus
Working directory: '`pwd`'
Date: `date`
OS info (uname -a): '`uname -a`'
Current user: `id -un`"

# Quote wine parameters
WineParams=""
for param in "$@"
do
WineParams="$WineParams '$param'"
done

WineCmdInfo="----------------------------------------------------------
Command: \"$wine$WineParams\"
----------------------------------------------------------"

logname="$logpath/$1.$date.$winever.log"

(
echo "$BasicInfo"
# Commands with potential multi-line output
if [ -x "`which glxinfo`" ] # Run only if glxinfo is in the path
then
echo '---------'
echo "Glxinfo strings matching '^OpenGL.*string|^direct rendering:':'"
"`which glxinfo`" |egrep '^OpenGL.*string|^direct rendering:'
fi
echo "$WineCmdInfo"
"$wine" "$@" 2>&1
echo "----------------------------------------------------------"
) |tee "$logname"

################################ End

Sample output:
mohag@mohagpc:~/bin$ WINE=wine wine_with_log winecfg
----------------------------------------------------------
Wine version: wine-1.1.24
WINEPREFIX: '/home/mohag/.wine'
WINEPREFIX state: Pre-existing
Working directory: '/home/mohag/bin'
Date: Sat Jun 27 10:45:56 SAST 2009
OS info (uname -a): 'Linux mohagpc 2.6.28-13-generic #44-Ubuntu SMP
Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux'
Current user: mohag
---------
Glxinfo strings starting with 'OpenGL.*string'; 'direct rendering:'
direct rendering: Yes
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTS 250/PCI/SSE2
OpenGL version string: 3.0.0 NVIDIA 180.44
OpenGL shading language version string: 1.30 NVIDIA via Cg compiler
----------------------------------------------------------
Command: "/usr/bin/wine 'winecfg'"
----------------------------------------------------------
fixme:mixer:ALSA_MixerInit No master control found on USB Device
0x46d:0x89d, disabling mixer
----------------------------------------------------------

[James McKenzie]

Gert van den Berg wrote:

On Thu, Jun 25, 2009 at 00:18, Martin Gregorie<[email protected]> wrote:

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.

All SUS-complaint unixes have a /bin/sh. Which might be a Bourne shell
(e.g. Solaris), POSIX shell (HP-UX), link to ash / dash / bash
(Various Linux / BSD version).... It ussualy run Bourne-scripts, but
might support various extensions which may not work in other shells.

Gert:

It's sh for MacOSX Leopard.

James McKenzie

[austin987]

On Sat, Jun 27, 2009 at 8:37 AM, James
McKenzie<[email protected]> wrote:

Gert van den Berg wrote:

On Thu, Jun 25, 2009 at 00:18, Martin Gregorie<[email protected]> wrote:

Minor point: I think all unices have the Bourn Shell but not all have
ksh, csh or bash, so the #!/bin/sh line is probably a good idea.

All SUS-complaint unixes have a /bin/sh. Which might be a Bourne shell
(e.g. Solaris), POSIX shell (HP-UX), link to ash / dash / bash
(Various Linux / BSD version).... It ussualy run Bourne-scripts, but
might support various extensions which may not work in other shells.

Gert:

It's sh for MacOSX Leopard.

No, /bin/sh for OS X is bash:
mac-mini:~ austin$ /bin/sh
sh-3.2$ echo $SHELL
/bin/bash

--
-Austin

[perryh]

All SUS-complaint unixes have a /bin/sh ... It ussualy run
Bourne-scripts, but might support various extensions which
may not work in other shells.

...

I take your point about non-standard extensions, but the way
round that is to stick to the original Bourne shell syntax and
not use the extensions.

Which is all well and good, provided one is aware of what
is and is not an extension. Absent a true Bourne shell for
testing, extensions may easily turn up in a script that was
intended to be portable.

[Martin Gregorie]

On Sat, 2009-06-27 at 15:39 -0700, [email protected] wrote:

All SUS-complaint unixes have a /bin/sh ... It ussualy run
Bourne-scripts, but might support various extensions which
may not work in other shells.

...

I take your point about non-standard extensions, but the way
round that is to stick to the original Bourne shell syntax and
not use the extensions.

Which is all well and good, provided one is aware of what
is and is not an extension. Absent a true Bourne shell for
testing, extensions may easily turn up in a script that was
intended to be portable.

Nobody said its easy, but its not hard either. There are ways to get a
decent handle on a portable shell scripting subset:

- stick to the syntax in short get-you-going books like
"Unix in a Nutshell" (O'Reilly) which clearly distinguishes
the syntax used by the UNIX SVR4 Bourn shell from ksh syntax.
At least my copy does.

- compile and install the Heirloom Bourn Shell, available
from SourceForge. It is specifically designed for portable
script testing.

- if you can't use those approaches, simply avoid everything except
basic features. Restricting yourself to the following may be overkill
but should do the job:
- use if..then..fi instead of defaulted assignments and
case...esac constructs
- avoid function declarations - you can always call another script
- use only the most basic for loop: for f in $* do...done
- use expr for all calculation and regex matching, not fancy
assignments
- stick to the simple conditions: -s -z -f -r -eq -ne < > !
- be prepared to recode anything that's even slightly complex
if it gets complaints.

This isn't made easy by the way 'compatibility' is maintained by various
Unices and Linuxes - in Fedora (and probably most current
Linuxes) /bin/sh is a hard link to /bin/bash so installing the Heirloom
Bourn Shell is probably the way to go.


Martin

[Gert van den Berg]

On Sun, Jun 28, 2009 at 00:39, <[email protected]> wrote:

I take your point about non-standard extensions, but the way
round that is to stick to the original Bourne shell syntax and
not use the extensions.

Which is all well and good, provided one is aware of what
is and is not an extension.  Absent a true Bourne shell for
testing, extensions may easily turn up in a script that was
intended to be portable.

I'll try testing on Solaris occasionally... It seem to at least be a
lot nearer to Bourne than bash.... dash is a another option. (I can't
find a package for the heirloom bourne shell)

http://docs.sun.com/app/docs/doc/816-5165/sh-1?a=view (/bin is a link
to /usr/bin on Solaris...)

Gert

[Gert van den Berg]

Can I add a link to the script in the FAQ under
http://wiki.winehq.org/FAQ#get_log ?

Gert

[austin987]

On Thu, Jul 2, 2009 at 12:43 PM, Gert van den Berg<[email protected]> wrote:

Can I add a link to the script in the FAQ under
http://wiki.winehq.org/FAQ#get_log ?

It's a freely editable wiki, so sure.

--
-Austin

[Gert van den Berg]

On Thu, Jul 2, 2009 at 19:47, Austin English<[email protected]> wrote:

On Thu, Jul 2, 2009 at 12:43 PM, Gert van den Berg<[email protected]> wrote:

Can I add a link to the script in the FAQ under
http://wiki.winehq.org/FAQ#get_log ?

It's a freely editable wiki, so sure.

Added to FAQ; added page for it. (The FAQ part might need a bit of
trimming and the page a bit of expansion)

Just wanted to be sure that it would not be considered in the same way
as posting 'Your game would probably work better under Cedega, you
might want to try that'...

I tried to make it clear that users should not expect support from
wine itself for problems with it, and that issues should be posted on
this thread.

Gert

[austin987]

On Thu, Jul 2, 2009 at 2:12 PM, Gert van den Berg<[email protected]> wrote:

On Thu, Jul 2, 2009 at 19:47, Austin English<[email protected]> wrote:

On Thu, Jul 2, 2009 at 12:43 PM, Gert van den Berg<[email protected]> wrote:

Can I add a link to the script in the FAQ under
http://wiki.winehq.org/FAQ#get_log ?

It's a freely editable wiki, so sure.

Added to FAQ; added page for it. (The FAQ part might need a bit of
trimming and the page a bit of expansion)

Just wanted to be sure that it would not be considered in the same way
as posting 'Your game would probably work better under Cedega, you
might want to try that'...

Well, it doesn't really do anything like cedega...just piping output.
It's not using a different wine codebase.

I tried to make it clear that users should not expect support from
wine itself for problems with it, and that issues should be posted on
this thread.

Good.

--
-Austin