When you specify alternate config files you don't need to specify a path. The location of the file is relative to the <mod>/cfg directory. Are people using config files outside of this directory?
I'll use backticks. $(...) is definitely a bash-ism. Ubuntu uses dash as its default /bin/sh and Debian uses bash I believe. I have come across a couple of places where some of my shell idioms haven't worked between these two distros. M. -----Original Message----- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andre Müller Sent: Saturday, January 15, 2011 3:22 PM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] srcds_run startscript First thing: cd $(dirname $0) #is maybe not the best solution Some systems doesn't use default bash for a user. Second thing, the normal srcds_run script uses /bin/sh, look at the head of the script. The shebang enforces it. So the POSIX command substitution isn't supportet in bourne shell. On some distibutions /bin/sh is a symlink to /bin/bash (Debian), but in example Ubuntu have bourne shell installed. When you don't change the shebang to #!/bin/bash you have to use the old way for the command substitution. -> cd `dirname $0` #this will work on all systems. There isn't an option to send the full Path to srcds_run You can use +exec configfile or +servercfgfile alternative_server.cfg but you could not say the runscript to run under a differrent path. The srcds_linux needs the libs from /bin or /orangebox/bin, so the srcds_run script first exports the LD_LIBRARY_PATH: # setup the libraries, local dir first! export LD_LIBRARY_PATH=".:bin:$LD_LIBRARY_PATH" Syntax: ./srcds_run [-game <game>] [-debug] [-norestart] [-pidfile] [-binary <binary>] [-timeout <number>] [-gdb <gdb>] [-autoupdate] [-steambin] [-steamerr] [-ignoresigint] [-steamuser <username>] [-steampass <password>] [-steamverify] [-debuglog <logname>] Params: -game <game> Specifies the <game> to run. [Default: ] -debug Run debugging on failed servers if possible. -debuglog <logname> Log debug output to this file. -consolelog <logname> Log console output to this file. -norestart Don't attempt to restart failed servers. -pidfile <pidfile> Use the specified <pidfile> to store the server pid. -binary <binary> Use the specified binary ( no auto detection ). [Default: ./srcds_linux] -timeout <number> Sleep for <number> seconds before restarting a failed server. -gdb <gdb> Use <dbg> as the debugger of failed servers. -steambin <path> Path to steam binary. -steamerr Quit on steam update failure. -steamuser <username> Use this username for steam updates. -steampass <password> Use this password for steam updates (-steamuser must be specified as well). -steamverify Force steam to verify the install on updates -ignoresigint Ignore signal INT ( prevents CTRL+C quitting the script ). -notrap Don't use trap. This prevents automatic removal of old lock files. Note: All parameters specified as passed through to the server including any not listed. Do you see any option to tell the script, which cwd is given? Ah sorry i've forgotten to import english ^^ Greetings DeaD_EyE 2011/1/15 Sherwood McGowan <sherwood.mcgo...@gmail.com>: > Can I ask something here, and please understand I'm not > trolling/flaming, but it's apparent that some of the people who have > contributed to this discussion are not the most experience Linux > admins so this question I think needs to be asked. > > Has anyone tried making sure that the script is giving the path to the > configuration file? See, if you're using a relative path in either an > argument, or in the config, and the binary does not have the proper > checks (i.e. determining where it's actual location is vs the working > directory of the user at the time of execution), you may need to be > explicit and use FULL PATHS. > > Many dedicated server binaries are ported to linux quickly, by people > who are capable of performing the port but are not as aware of some of > the nuances between how different operating systems work, so sometimes > you come across issues like this where you have to configure scripts > and configurations in a different way in order to bypass issues > stemming from a ported binary that was not written in a completely > Linux compatible way. > > There are several things I would try before giving up and using a > method like the one below (again, this is not a slam, cheers to ya for > providing the community a working solution), and it doesn't sound like > they've been tried. The first would be going through your > configurations and arguments supplied and understanding how they call > on another. Another is to check to see if there's a place where you > can define the "root" directory for the server instance you are trying > to start....If you can do that, your relative path issue is solved... > > I could sit down and spend probably an hour thinking of the various > things to check and test, but unfortunately I'm from the school of > "give them a nudge in the right direction, they'll learn a bit and > possibly find a solution". > > Let me close by saying I know that you don't know me, that this is my > first post, and you may be thinking "this guy is a [insert > insult/expletive here]", but I will say again that I'm not trying to > be a dick. This was not a troll or a flame. > > Thank you, good night, and good luck, I hope that this helps you find > a graceful solution. > > Sherwood McGowan > ...Downloaded Linux on a 56k modem... > > On Fri, Jan 14, 2011 at 4:05 PM, Milton Ngan <mil...@valvesoftware.com> wrote: >> I'll take a look at fixing this. The suggestion was to add the line: >> >> cd $(dirname $0) >> >> to the start of the script. This should address the issue of having to be in >> the same directory as the script to run it. > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
