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.
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
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
Doesn't change the fact the gdb freezes Portal. You're still ultimately using gdb in you're solution, right?
Why not just Code: 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
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 [Wink] 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
You explain each and every thing very clearly thanks.
Greetings, my name is lewis dsaxt Recently from Nebraska, originally from Chicago and grew up there. I have a great family,I love to experience all cold weather , specially the Fall and with all its colors. Learning new things has been a part of my life for the last few years and most recently primarily on the Internet. I love the Internet. Things as they are, more and more people are seeking help from people who have walked the walk and can teach others how to benefit from their experience. Message me if you need my help I am a manager in the field of Science time management software. Learning about new things is one of my passions. when possible I volunteer for for valid causes that help the environment. Glad to be a part of this Website and hope I can help.
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.