Bash Script Shorcuts for Steam Games

Entanglement · Post by **Entanglement** » Sat Sep 24, 2011 12:18 am

Hi there,

I was just wondering how I would go about creating a bash script for Steam apps. I just started college in Pre-Biochem. and Pre-Comp. Sci. so I'm not far enough in yet (and midterms are coming up, how embarrassing) but the point is, I don't know how to create a bash script for steam apps.

I know they start up steam first, then log in, and then get into the game. I'm not sure how to do this much complex bash scripting.

I do however have some knowledge with bash as I've created a few basic scripts for class, and I have one for other wine programs and other programs in general.

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 1:03 am

Hello Entanglement!

Are you in Linux? If so, then you can make launchers, which have pretty icons. Why use a script if you can have a launcher?

Either way, the contents of a launcher and the contents of a bash script are exactly the same.

The following runs Portal:

env WINEPREFIX="/home/shjake/steam" wine C:\\windows\\command\\start.exe steam://rungameid/400

How on Earth did I know that? I didn't. I just copied and pasted it out of an automatically generated launcher that got put on my desktop.

If you are in Linux, you should be getting automatically generated launchers on your desktop, or maybe that's only if the program normally puts a shortcut on the desktop.

But you can keep going just fine without automatically generated launchers, you just have to manually make them.

Since your question was about how to make a bash script, I will answer that first.

Make a new blank file. Most GUIs let you right-click the desktop or in any folder, go to "New", and then "text document" or "empty file" or something like that. The Mac OS X GUI does not have that feature by default, but there is a way to make it have it. Gnome has it under "Create Document" by default.

Open the file up in a plain text editor (gEdit, Mac's plain TextEdit or whatever it's called, etc. As opposed to LibreOffice Writter or MS Word.) Just paste the "code" right in the file and save it.

Then, if in Linux, right-click the file, go to properties, go to the permissions tab, and check to allow the file to run as a program. If your GUI doesn't have that option, there is a way to do that in terminal that I don't know off the top of my head.

Now double-click the file and choose "run", and it should run.

The "env" says that you're about to define an environmental variable, WINEPREFIX in this case. WINEPREFIX specifies the WINE prefix I have the program installed in (duh). A WINEPREFIX is a folder that WINE can use as a C: drive. Yes you can have more than one, and yes, each one is like it's own little "WINE world".

The "wine" isn't just a universal command to run wine. It's actually a file name at the assumed location of /usr/bin. If the file was named bob, you would actually write "bob" instead of WINE. if the WINE executable was somewhere other than /usr/bin, you would likely have to write out the full path to it in place of merely writing "WINE".

The next part has WINE run start.exe to run Portal in some extraterrestrial syntax.

Now making a launcher (in Ubuntu-like distros of Linux):

Right-click the desktop or wherever, click "Create Launcher". There will be a wizard. It is of type "Application". Give it a name, and paste in the command discussed earlier. Click the picture of a spring-board (the default launcher icon) and pick a relevant icon if you have one. If you missed the wizard, right-click the new launcher and go to properties. Give it a name, perhaps a description, and paste in the command as discussed earlier.

To acquire a relevant icon, you can download IconsExtract and extract the icon from the exe as an ico. You can then use GIMP select one layer of the ico, and save that layer as a png. You can then use that png as the picture for the launcher.

How the automatic launcher generator gets the relevant icon for the launcher, I don't know. I just opened a launcher with gedit, and for the icon it says "546C_c7cb09b9f0fbb9589b4bd5a8217c8333c4d8204e.0". I think I'll stick with IconsExtract + GIMP. It's fairly simple. The multiple layers part might throw you off for a while, but once you find a method, like making a copy of the ico and deleting the other layers, or making the other layers invisible or something, you'll be fine.

Cheers,
Jake

Entanglement · Post by **Entanglement** » Sat Sep 24, 2011 1:21 am

SpawnHappyJake:

Are you in Linux? If so, then you can make launchers, which have pretty icons. Why use a script if you can have a launcher?

Yes, I'm using Slackware 13.37 64-bit with 32-bit compatibility libraries. I know I can make Launchers (my Desktop allows them) but I just personally don't like them which is why I chose to make a script.

Although I did ask how to make a bash script, I already have made some for a few other programs in Wine, so I do know the basics.

However, I don't know complex bash scripting, which is what I was trying to go for.

You see, one of my steam apps uses hl2.exe, but unfortunately that isn't very compatible with AMD/ATI graphics cards, so I want to run gnu debugger to find the pid of hl2.exe at the time, which is done as so:

Code: Select all

ps -ef | grep hl2.exe

But I want to change some parts of hl2.exe by this:

Code: Select all

gdb --pid ####

And then insert my commands like 'handle PART nostop noprint' blah de blah, but I don't know how to go that far with bash scripts. That is what I was primarily asking for.

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 1:46 am

Don't know if this helps, but I made a bash script with the following:

Code: Select all

env WINEPREFIX="/home/shjake/steam" wine C:\\windows\\command\\start.exe steam://rungameid/400

ps -ef | grep hl2.exe

Then when to terminal and did:

Code: Select all

'/home/shjake/Desktop/Portal' &> ./Desktop/run.log

"Portal" being the name of the script.

run.log contains this:

fixme:exec:SHELL_execute flags ignored: 0x00000100
shjake 5498 5492 0 23:32 pts/0 00:00:00 grep hl2.exe

Am I getting any closer to what you want?

I guess now we have to figure out how to pass one of those process ids to the gdb thing. The process id for hl2.exe changes each time.

Cheers,
Jake

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 7:42 am

Hey, I think there is a bug with gdb. Yes, a bug in the debugger. Other than that, I got it figured out.

You should be able to open terminal, enter "su -", and log into a superuser shell.

From there you should be able to run something like the following script:

Code: Select all

/bin/su - shjake -c "env WINEPREFIX=/home/shjake/steam wine /home/shjake/steam/drive_c/windows/command/start.exe steam://rungameid/400" &

sleep 25s

hl2Pid=`pgrep hl2.exe`

gdb --pid $hl2Pid &> /home/shjake/Desktop/hl2dbg.log

I keep getting this error back:

Code: Select all

.llegal process-id: [insert number here]

Even if I change "hl2Pid=`pgrep hl2.exe`" to "hl2Pid=`pgrep firefox`" when firefox is running, comment the first two lines out, and just run those last two, I get that error.

But if I copy and paste those exact same lines into the superuser shell, I get debugging info about firefox spewed into hl2dbg.log like I should.

If it weren't for this bug, this is what would be happening:
You are "logged" in as the superuser. Everything has root privileges unless specifically stated otherwise.
The first line uses

Code: Select all

/bin/su - [user name] -c "[command]"

to run Portal in WINE as the normal user that owns WINE. Running WINE as root breaks it.
The first line ends in "&", this makes the next line start even though the first line isn't "done" yet. That's what we need. It won't be "done" until Portal is closed out. In fact, it runs both the first line and the second line at the same time.

The second line gives enough time for the hl2.exe process to appear. You can't run the first line and the third line at the same time, or else we might not find a pid for hl2.exe, because it doesn't exist yet.

The third line creates a variable and passes the pid of hl2.exe to it.
The fourth line is supposed to take the pid out of the variable, use it with gdb, and output debugging info into a log file, but fails to do so from a script, and only works at the "live" terminal.

Hope this gets somewhere,
Jake

Mateusz Stachowski · Post by **Mateusz Stachowski** » Sat Sep 24, 2011 7:53 am

Hello Entanglement and SpawnHappyJake,

I also prefer to make my own launcher scripts than relying on winemenubuilder which is a very poor implementation. If you let it to run it will polute your menu with tons of unnecesary shortcuts (like Readme or Uninstall this or that, Windows Media Player or iTunes thingies) so for me it's better to disable it:

winemenubuilder.exe (in winecfg libraires set to disabled)

I'm using that template of bash script:

Code: Select all

#!/bin/sh 
export WINEPREFIX="/media/Ubuntu/.wine-steam" 
cd $WINEPREFIX/drive_c/Program\ Files/Steam/ 
wine-git Steam.exe 2>&1 | tee wine.log

That doesn't start the game but Steam and then I'm launching my app. If you want to see the fps counter you could do it like that:

Code: Select all

#!/bin/sh 
export WINEPREFIX="/media/Ubuntu/.wine-TheWitcher2" 
cd $WINEPREFIX/drive_c/Program\ Files/The\ Witcher\ 2/ 
WINEDEBUG=fps wine Launcher.exe 2>&1 | tee /dev/stderr | grep --line-buffered "^trace:fps:" | osd_cat

When using Steam I also encountered error when it's reaching 26% of the update and hangs. Strangely when I have the fps counter commands in my script the update goes well.

Entanglement · Post by **Entanglement** » Sat Sep 24, 2011 1:19 pm

Thanks guys, I've successfully made my way to making scripts that can launch the game, but unfortunately I still lack how to automagically use GNU Debugger to fix the hl2.exe problem.

Currently I'm thinking about using an echo command via opening a terminal when hl2.exe loads, but am unsure of:

a) How best this option is.
b) How to change the script to do this in general.

Martin Gregorie · Post by **Martin Gregorie** » Sat Sep 24, 2011 1:36 pm

On Sat, 2011-09-24 at 13:19 -0500, Entanglement wrote:

Thanks guys, I've successfully made my way to making scripts that can
launch the game, but unfortunately I still lack how to automagically
use GNU Debugger to fix the hl2.exe problem.

Have you tried using a HERE document? its fully described in the bash
manpage.

Martin

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 2:48 pm

Have you at least gotten debugging information about hl2.exe from gdb?

If not,
My method would work if you ran the game in a Window (like how the Portal entry in the AppDB says) or somehow minimized the game after it goes full-screen, or, probablly best, used a virtual desktop.

That way you can get to a terminal and input those last two lines manually while hl2.exe is running. The bug is only when they come from a bash script. It works "live". You could even prepend them with "sudo" instead of dropping to a superuser shell. And that would mean you could remove the "specify user" stuff off the first line, because you'd be logged in as you to begin with.

So you could have two terminals open (or one with 2 tabs). One could be running the steam game, and the other would send the debug info you want into a log file, using gdb.

Or just one terminal/tab. It would get the debugging stuff, and you could just run the game "straight", as from a launcher or something (i.e. without terminal).
Cheers,
Jake

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 4:21 pm

Hmm. Seemed like I got it to work once. Now whenever I attach hl2.exe to gdb, Portal freezes. When I close the terminal to unattach it, Portal unfreezes.

I got excited, because I then tried it without sudo, and it didn't freeze, and it looked like it was doing its job, but the log said that it could not attach to the process.

Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.

Jake

SpawnHappyJake · Post by **SpawnHappyJake** » Sat Sep 24, 2011 6:36 pm

Darn. Even if I do this from a terminal while Portal is in an emulated desktop:

Code: Select all

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
hl2Pid=`pgrep hl2.exe`
gdb --pid $hl2Pid &> /home/shjake/Desktop/hl2dbg.log

I get the freeze.

I got this in my log:

Code: Select all

Attaching to process 4397
Reading symbols from /usr/bin/wine_1.3.29/bin/wine-preloader...done.
0xf778742e in __kernel_vsyscall ()
(gdb) Hangup detected on fd 0
Error detected on fd 0
error detected on stdin
A debugging session is active.

	Inferior 1 [process 4397] will be detached.

Quit anyway? (y or n) EOF [assumed Y]
Detaching from program: /usr/bin/wine_1.3.29/bin/wine-preloader, process 4397

Jake

Martin Gregorie · Post by **Martin Gregorie** » Sun Sep 25, 2011 4:52 am

On Sat, 2011-09-24 at 18:36 -0500, SpawnHappyJake wrote:

Darn. Even if I do this from a terminal while Portal is in an emulated desktop:

Code:

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
hl2Pid=`pgrep hl2.exe`
gdb --pid $hl2Pid &> /home/shjake/Desktop/hl2dbg.log

Have either of you tried here documents? Here's a tested example:

================start of testscript================
#!/bin/bash
echo "Starting cat read lines from a here document ended by EOF"
cat <<EOF
line 1
line 2
EOF
echo "End of example here document"
=================end of testscript=================

Substitute gdb for cat and gdb commands for 'line 1' and 'line 2'. This
should work a lot better than echo because you can put as many lines as
you want in the here document. You can also use shell variables for text
substitution in it - see the bash manpage f0or details.

Martin

SpawnHappyJake · Post by **SpawnHappyJake** » Sun Sep 25, 2011 6:13 am

Doesn't change the fact the gdb freezes Portal. You're still ultimately using gdb in you're solution, right?

Entanglement · Post by **Entanglement** » Mon Sep 26, 2011 2:19 pm

Sorry for the late reply, I'm very busy with exams coming up (mid-terms).

Okay, so yes I do plan on using GNU Debugger, and just to help you out too, the command "c" under GNU Debugger will continue Portal.

Anyways, here's what I am trying to execute:

Code: Select all

ps -ef | grep hl2.exe

To find hl2.exe's profile #.

Code: Select all

gdb --pid #####

The #'s refer to the hl2.exe pid.

and then with gdb:

Code: Select all

(gdb) handle SIGSTOP nostop noprint
(gdb) handle SIGSEGV nostop noprint
(gdb) handle SIGUSR1 nostop
(gdb) c

What I want to do is use the gdb --pid code and the gdb commands as soon as hl2.exe is detected from Team Fortress 2 in my bash script.

Martin Gregorie · Post by **Martin Gregorie** » Mon Sep 26, 2011 2:54 pm

On Mon, 2011-09-26 at 14:19 -0500, Entanglement wrote:

Sorry for the late reply, I'm very busy with exams coming up (mid-terms).

Okay, so yes I do plan on using GNU Debugger, and just to help you out too, the command "c" under GNU Debugger will continue Portal.

Anyways, here's what I am trying to execute:

Code:
ps -ef | grep hl2.exe

Firstly, you need to trim this to just the pid and capture the result as
a shell variable:

<code>
pnum=$(ps -ef | gawk '$8 == /ntpd/ { print $2 }')
</code>

and then you can pass it to gdb, which should read its commands from a
here document:

<code>
gdb --pid $pnum <<EOF
handle SIGSTOP nostop noprint
handle SIGSEGV nostop noprint
handle SIGUSR1 nostop
c
EOF
</code>

I've tested the first code fragment but not the second.

Martin

To find hl2.exe's profile #.

Code:

The #'s refer to the hl2.exe pid.

and then with gdb:

Code:
(gdb) handle SIGSTOP nostop noprint
(gdb) handle SIGSEGV nostop noprint
(gdb) handle SIGUSR1 nostop
(gdb) c

What I want to do is use the gdb --pid code and the gdb commands as soon as hl2.exe is detected from Team Fortress 2 in my bash script.

Martin Gregorie · Post by **Martin Gregorie** » Mon Sep 26, 2011 3:30 pm

On Mon, 2011-09-26 at 20:53 +0100, Martin Gregorie wrote:

<code>
pnum=$(ps -ef | gawk '$8 == /ntpd/ { print $2 }')
</code>

This should, of course, have been:
<code>
pnum=$(ps -ef | gawk '$8 == /hl2.exe/ { print $2 }')
</code>

..but that's what happens when you copy & paste working code from the
terminal and then don't read it afterwards.

Martin

SpawnHappyJake · Post by **SpawnHappyJake** » Mon Sep 26, 2011 8:35 pm

Why not just

Code: Select all

hl2Pid=`pgrep hl2.exe`
gdb --pid $hl2Pid [insert other stuff here. Hehe. "here"]

To pass the PID on?

Also, I thought that the point of attaching a process to a debugger is to get a constant spewing of debuggery as the process runs, especially during extended user interaction. Here it looks like gdb pauses a process, dumps some stuff, and then you can resume the process, ending the debugger. So you only get snapshots instead of a live feed.

Please tell me that there is a way to have such a live feed. Append "-c" with the other parameters?

Also, how do you stop the debugger in terminal, if that's what terminal is currently running? Usually Ctrl+c ends a command/ program in terminal, and man pages are different in that they are ended in "q" rather than Ctrl+c, but I tried both of those, and they don't kill the debugger. I have to close terminal and open another one.

Jake

Martin Gregorie · Post by **Martin Gregorie** » Tue Sep 27, 2011 4:54 am

hl2Pid=`pgrep hl2.exe`
gdb --pid $hl2Pid [insert other stuff here. Hehe. "here"]

Because you have to know that it exists? "apropos pid" doesn't find it
on my system. "apropos grep" does, but this somewhat begs the question,
since to find it this way you need to know that a grep clone is
involved. In any case, ps, grep and gawk are standard utilities on
almost any Linux or BSD system: can you say the same for pgrep, zgrep or
mboxgrep?

Also, I thought that the point of attaching a process to a debugger is
to get a constant spewing of debuggery as the process runs, especially
during extended user interaction.

Thats news to me. Every debugger I've used has been interactive: you can
ask for stack dumps or to see or set variable values, step the program,
set break or watch points etc.

Generally speaking, using a debugger is a very slow way and often
frustrating way to find out what a program is doing and tell it it
mustn't. This is why a well-written program contains both assert
statements and tracing statements that are controlled by command line
debugging arguments.

Please tell me that there is a way to have such a live feed. Append
"-c" with the other parameters?

gdb is a pretty good debugger if you need one, so try "man gdb" and be
prepared fro quite a long read.

Also, how do you stop the debugger in terminal,

Usually by detaching it when it reaches a breakpoint and stops.

Martin

SpawnHappyJake · Post by **SpawnHappyJake** » Tue Sep 27, 2011 10:34 am

Well Martin, this has been a learning experience for me. I quickly read the gdb man page (got some homework to do). It wasn't that long of a read. Not compared to my religion reading

I ran Portal and attached gdb to hl2.exe. Portal froze. I tried the "c" for continuing hl2.exe in gdb in terminal, and this did unfreeze Portal for a bit, but once I clicked "load" in Portal, the debugger says it gets a segmentation fault, and Portal freezes. I quit gdb with "q", and Portal unfreezes.

One time I tried either "step" or "next" instead of "c", can't remember which, and it froze my whole system, except for the mouse. Had to use the power button. Interesting.

Anyways, from my lay-man's perspective, I thought that, for example, running a Windows program in WINE in terminal and getting that log was "running a debugger" because you got lots of info about was was going on, especially when a bug happens, thus is a "debugger." I thought gdb would give something similar. But it looks like there is logging, and there is debuging. And that some programs have features put in that are accessed only by a debugger, even after compilation, is a new insight to me - thanks, Martin.

I knew that when writting a program in an IDE there are several debugging tools available to you, such as stoping at certain lines and seeing what variables equal at different times. But that's with source code. I didn't know that something similar could be done with a compiled program, like this hl2.exe.

I went here: http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html, and learned a few things. But the examples they give only work because gdb has both the source code and the compiled program. We don't have the source code for hl2.exe, so how is this working? Also, I noticed that you can run "wine" through gdb at terminal, but not "firefox". Is it just a matter of some compiled programs supporting debugging, and other not?

And I noticed that Program Files\Steam\dumps has several crash_hl2.exe_[date and time]_1.dmp files. And they sure don't open in gedit. I did notice in the gdb man page that gdb has an option to use core dump files. gdb -c [steam dump file] made gdb say that it wasn't a core dump file. It said that the file format is not recognized, which is what it says when I try to run FireFox through gdb. I just thought that was an interesting coincidence and should share it. It's probably still related to debugging hl2.exe.

Jake

Kitee · Post by **Kitee** » Tue Sep 27, 2011 11:53 am

You explain each and every thing very clearly thanks.

Martin Gregorie · Post by **Martin Gregorie** » Tue Sep 27, 2011 5:48 pm

On Tue, 2011-09-27 at 10:34 -0500, SpawnHappyJake wrote:

I ran Portal and attached gdb to hl2.exe. Portal froze. I tried the
"c" for continuing hl2.exe in gdb in terminal, and this did unfreeze
Portal for a bit, but once I clicked "load" in Portal, the debugger
says it gets a segmentation fault, and Portal freezes. I quit gdb with
"q", and Portal unfreezes.

I would sort of expect that: debuggers are generally written in tandem
with the compiler they expect to work with because they need a detailed
understanding of the way the compiler emits code and its relationship to
the source and, of course, the compiler's data storage allocation
strategy. If the binary doesn't agree with its expectations or it
doesn't understand the symbol table the compiler generated its can't do
a lot, as you've seen.

gdb expects to debug code generated the matching version of gcc just as
the Visual C debugger works with the Visual C compiler and the Borland C
compiler had its own debugger. I wouldn't expect any of these debuggers
to work with executables from the other compilers.

BTW, I should have added that IMO debuggers are getting increasingly
obsolete. When computers were slow, even simple programs took minutes to
compile a debugger was essential, and you were lucky to get one
compilation run a day, debuggers were A Good Thing because using one was
so much faster than recompiling the program. This us why a debugger can
path the program on the fly and can often save the image so its
rerunnable: in those days we used to patch bugs with the debugger so we
could go on finding other bugs. At the end of the day you applied those
changes to the source and stuck it in the queue for the overnight
compilation run. Now that compilation of even quite large programs is
almost instant, debugging with the aid of diagnostics such as Wine can
output is very much faster.

I haven't used a debugger since the last time I was working on a Tandem
NonStop system back in the mid '90s.

War story: a tape-based assembler I used while I was first learning to
write assembler and we were all writing tiny 200 line programs and
punching them on cards was so slow that you could grab your card deck
from the output hopper, get the print-out from the printer, fix the
errors with a hand punch and get the corrected cards back in the input
hopper before the computer had finished compiling the equal sized
programs written by the other 5 course members. This machine had 4 tape
decks, card reader, line printer (no disks at all) and took 12 uS to do
a half-word add, so its clock speed was around 0.08 MHz

Anyways, from my lay-man's perspective, I thought that, for example,
running a Windows program in WINE in terminal and getting that log was
"running a debugger" because you got lots of info about was was going
on, especially when a bug happens, thus is a "debugger." I thought gdb
would give something similar. But it looks like there is logging, and
there is debuging. And that some programs have features put in that
are accessed only by a debugger, even after compilation, is a new
insight to me - thanks, Martin.

Yep. Debugging is OK for really small programs, but its at far too
fine-grained a level of detail for anything of any size and complexity:
you spend forever messing about setting break points and finding that
they're not really where you want them and repeating the exercise
endlessly. Its much better to add display statements that report where
the programs is at and shows you the interesting data at that point in a
sensible format. You can even do better: throw the tracing output into a
circular buffer and only display its contents when the program hits a
problem and quits -this way you know why it quit (you do use sensible
error messages, don't you?) but also get a backtrace showing what it had
been doing before it stopped. No debugger can do that, especially if the
program is one that normally runs continuously for days at at a time.

I went here: http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html,
and learned a few things. But the examples they give only work because
gdb has both the source code and the compiled program.

A debugger is remarkably useless if you don't have the current source in
front of you - how else will you know where to put break points.

gdb -c [steam dump file] made gdb say that it wasn't a core dump file.

... because it almost certainly doesn't contain either binary data or
symbol tables output by the same version of gcc that your copy of gdb
was compiled to work with.

Martin

Entanglement · Post by **Entanglement** » Tue Sep 27, 2011 10:56 pm

Okay, so I tried the code you gave me Mr. Gregorie (including your new post's fix on ps -ef) but GNU Debugger still failed to run on the script (which currently only has TF2's launch from wine line on it).

SpawnHappyJake · Post by **SpawnHappyJake** » Wed Sep 28, 2011 3:11 am

Thanks Martin! I loved that war story!

So it looks like Entanglement will have to change strategy, since hl2.exe is not compatible with gdb. Hl2.exe was not compiled in gcc, I'm sure. It is a commercial, non-open source Windows program.

Whenever I search for debugging hl2.exe, Visual Studio comes up. That's probably the debugger that works with hl2.exe.

I got a little excited when I saw this: http://www.tenstones.net/forums/general ... tches.html, but alas, it is all bogus. At least my attempt of using them didn't pan out. That's probably why it was followed by an expletive comment (not from me).

Entanglement, how did you acquire knowledge of debugging commands for hl2.exe?

Also, do you have the hl2.exe source code and/or Visual Studio at your disposal?

Would using the WINE debugger help? Or even a plain log from running in WINE in terminal?

I can't help but feel you won't get far without the hl2.exe source code.

I have an ATI graphics card in my computer, and I play Portal 1 (which uses hl2.exe) (just did a couple bonus maps

) in Steam in WINE. And I do have graphics issues when not in an emulated desktop or otherwise windowed mode. The mouse shows in the middle of the reticle, things get flickery and show through other things, especially around the energy bullet shooters, purple flickers come through objects, especially the portal gun when holding it. There's also points where the mouse gets out of sync with the reticle, causing the game to freeze for a while. But when I use the windowed mode specified in the AppDB, that all goes away. Also the community do-dad feature needs to be turned off as specified in the AppDB for Portal, or else the game crashes when the first portal tries to load. Normally I can put up with the glitches for the sake of fullscreen. Does any of this describe your symptoms? Have you tried the windowed mode or the emulated desktop (two different things)?

Cheers,
Jake

Martin Gregorie · Post by **Martin Gregorie** » Wed Sep 28, 2011 6:53 am

On Tue, 2011-09-27 at 22:56 -0500, Entanglement wrote:

Okay, so I tried the code you gave me Mr. Gregorie (including your new
post's fix on ps -ef) but GNU Debugger still failed to run on the
script (which currently only has TF2's launch from wine line on it).

I have only responded with tips about writing bash scripts, since that
was what you asked about. I had assumed, possibly incorrectly, that you
*KNEW* that using gdb to adjust the signal handling for SIGSTOP, SIGSEGV
and SIGUSR1 would allow HL2.exe to run successfully. I have not and will
not offer advice on using gdb since I don't use it myself, except for
this point: altering the behaviour of the SIGSEGV handler is not a good
idea since that traps memory segmentation faults, i.e. program crashes
due to trying to address memory outside itself.

Have you done this gdb procedure manually and had HL2.exe run correctly
as a result? If not, there's little point in trying to script something
that doesn't work when you type it by hand. If you have had it work
using manual command line input, please post a screen dump via pastebin
that shows the commands you issued and the responses made by gdb and
your program. I also want to see proof that gdb is reading the symbol
table from HL2.exe.

The reason I'm asking to see this output is because the only fragment of
gdb output I can find in this thread was in a post from Jake, which
shows gdb reading the symbol table of the Wine preloader. That symbol
table has nothing whatsoever to do with HL2.exe

Once we've seen the manually entered sequence of commands that cause
HL2.exe to run correctly we can advise on how to script it.

Martin

Entanglement · Post by **Entanglement** » Thu Oct 06, 2011 12:52 am

Hi there Martin,

Sorry for the late reply. This week was when many of the exams were being prepared for (and some even came this week) so I was busy.

I'm bumping it to say that I will post the information you ask for as soon as possible, but I wanted to bump it so that I do not lose track of this thread.