<p>I have a segment of code that is dealing with strings and string slices. I have an external go file that is used entirely for config purposes, and am attempting to pull in the elements of a string slice from it to the main source file. The code I want to simplify is:</p>
<pre><code> args := []string{"-dmS", screenname}
args = append(args, invocation...)
args = append(args, rootdir+servername+"/"+"server.jar")
</code></pre>
<p>Where screenname, rootdir, and servername are all strings, and invocation is a []string. Ultimately, I want args to contain all the elements of invocation, but be sandwiched on both sides by my other data.</p>
<p>How do I simplify this into something succinct and usable? This code as it is works, it's just ugly as all hell and I <em>know</em> that it's only this gross through my own inexperience.</p>
<hr/>**评论：**<br/><br/>skarlso: <pre><p>You could try using <a href="https://golang.org/pkg/flag/" rel="nofollow">Flags</a> and then you could concatenate the variables in whatever order you want them. Unless you are not dealing with runtime arguments. </p>
<p>Oh wait. You are using an external go file for confirmation? That's not right. You should use a json file for that! Are you restricted to a go file? If so, have the arguments in separate variables which you could then move around. </p>
<p>Also, if you don't want to use append you could try using slice indexes, like args[1:] and copy, but essentially it would leaf to the same conclusion. Without restructuring the way you are handling input right now there are limited options at your disposal. </p></pre>nathanpaulyoung: <pre><blockquote>
<p>You could try using Flags and then you could concatenate the variables in whatever order you want them. Unless you are not dealing with runtime arguments.</p>
</blockquote>
<p>That's certainly an idea, but I'm not receiving very much info from the commandline at all. My command line invocation only looks something like "msct start servername", where servername ends up being used in the invocation of a screen session for a Minecraft server. The actual invocation used for starting the server should be configurable, but not at runtime level.</p>
<p>What's more, I'm using codegangsta's CLI library, so I'm not sure how I'd fit flags into what I'm already doing, or how it'd help.</p>
<blockquote>
<p>Oh wait. You are using an external go file for confirmation? That's not right. You should use a json file for that! Are you restricted to a go file? If so, have the arguments in separate variables which you could then move around.</p>
</blockquote>
<p>I have every intention of eventually moving to toml or yaml. This is for my own personal use right now, and I just really don't mine a recompile to change a setting atm. Some day, it'll be on github, and config will matter.</p>
<blockquote>
<p>Also, if you don't want to use append you could try using slice indexes, like args[1:] and copy, but essentially it would leaf to the same conclusion. Without restructuring the way you are handling input right now there are limited options at your disposal.</p>
</blockquote>
<p>I don't think I understand.</p></pre>skarlso: <pre><p>Yeah, like I said, if you don't change the way you are parsing the setup, you have very limited options. :) </p>
<p>Forget about the copy. :) It would have been just as ugly, if not uglier. :) I would have suggested to use inserts with specific place and copy slice. But with append you are at least not confined to anything.</p></pre>nathanpaulyoung: <pre><p>Yeah, since my OP and y'all's replies, I've been thinking a lot about what I'm trying to do. I think the solution really is just to switch to a proper config file format. I'm looking at <a href="https://github.com/olebedev/config" rel="nofollow">olebedev/config</a>, and it seems really nice. Have you used it?</p></pre>joushou: <pre><p>JSON is not a very good format for configuration purposes. It quickly becomes unpleasant. I would suggest YAML, TOML, CSON, or even just newline separated key-value pairs. As someone dealing with <em>huge</em> JSON configuration files, you'll thank me once you get more than 3 keys in your file.</p></pre>skarlso: <pre><p>Let's agree to disagree. Json is a breeze to parse. And all the xML stuff is ugly and too verbose. :-)</p></pre>joushou: <pre><p>This is gross due to "invocation" being a slice. Could you give "screenname" as an argument <em>after</em> your invocation? That would make the code:</p>
<pre><code>args := append(invocation, "-dmS", screenname, rootdir+servername+"/server.jar")
</code></pre>
<p>You could also consider if you could use the result as a string:</p>
<pre><code>args := fmt.Sprintf("-dmS %s %s %s%s/server.jar", screenname, strings.Join(invocation, " "), rootdir, servername)
</code></pre>
<p>As for using a go file for configuration, it depends on the purpose. You could have a go file with compile-time constants if these options are not meant to change for <em>any</em> reason after delivery. Server configuration, however, should be in an external file of some sort, although I would <em>really</em> suggest that you didn't use JSON.</p></pre>nathanpaulyoung: <pre><blockquote>
<p>Could you give "screenname" as an argument after your invocation?</p>
</blockquote>
<p>I don't think I have that option. I'm using this as a server management tool for a Minecraft server, and I'm running it in a screen. I'm using codegangsta's cli library and receiving the servername on c.Args().First(). Then I build out the full body of exec.Command(cmd, args...), where args ends up being something along the lines of "-dmS msct-servername java -jar /full/path/to/servername/server.jar", and cmd obviously contains the actual "screen" command.</p>
<p>So I'm really just bumbling around trying to learn what defines "good form" for me. I did actually try fmt.Sprintf for the full invocation at one point, but exec.Command() didn't seem to like it.</p>
<blockquote>
<p>You could have a go file with compile-time constants if these options are not meant to change for any reason after delivery. Server configuration, however, should be in an external file of some sort, although I would really suggest that you didn't use JSON.</p>
</blockquote>
<p>Yeah, I may look into toml or yaml. Eventually this will be code up on github for people to use. Until then, recompiling to change options doesn't matter to me.</p></pre>
