[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ale] how do I - icon starts script starts 4 scripts



Perhaps the single more important tip I have for anyone writing any program or
script is that if the function is longer than your screen can show, then you
should break it up.  Everything that a function does should fit on a single
screen and be viewable all at once.  For me, than means 10-30 lines per
method/function/program.

This tip has saved me thousands of hours in troubleshooting - perhaps tens of
thousands of hours.

A few times in my career, I was forced to not write code in this way for reasons
outside my control and those programs were always highly buggy - before I
touched them.

When I'm not sure how a command works, I RTFM.  The man pages for most commands
contain tremendous information AND wisdom.

Lastly, if you are looking for examples of bash scripts, there are thousands on
every Linux system already. You just need to view them.

On 04/18/2013 10:59 AM, Jim Kinney wrote:
> I've been banging most everything in bash for the past 6 years so I've probably
> developed some bad habits.
> 
> In short, I try and treat all scripting like a third normal form database -
> i.e., write it once and reference it as needed. I've seen it to be good practice
> to put hard-coded variable (counts, paths, naming structures, etc) as variable
> at the top of the script. Make later maintenance easier. Anything that gets done
> more than once becomes a subroutine. Passing small data as parameters is the
> meat-n-potatoes of much of my scripting. As there are limits to the line
> lengths, I never pass more than a few (less than 5 if all required) but I may
> start with more than that (master starts with 10-15 mostly optional param) - use
> getopts to handle more than 2 or optional stuff.
> 
> Several people have recommended the Advanced Bash Scripting Guide. Add me to the
> list of recommenders.  It's well written with decent examples and good theory.
> Named arrays makes some peoples heads spin from a bash context, but it's usefull :-)
> 
> 
> On Thu, Apr 18, 2013 at 10:43 AM, Ron Frazier (ALE)
> <atllinuxenthinfo at techstarship.com <mailto:atllinuxenthinfo at techstarship.com>>
> wrote:
> 
>     __
>     Hi Jim,
> 
>     I might end up using the sleep command as you say.  Scott also mentioned
>     some variations on the read command.
> 
>     The alternate program structure you mentioned looks interesting.  I know
>     generally what you're doing with it, although I'll have to study it further
>     to understand the details.
> 
>     At first glance it looks somewhat cryptic compared to other languages.  I'm
>     not sure why.  Probably all the variables you're passing back and forth.
> 
>     Sincerely,
> 
>     Ron
> 
> 
>     On 4/17/2013 9:57 PM, Jim Kinney wrote:
>>     to add a delay, use sleep n where n is a number seconds to pause. You can
>>     use different units from seconds. Man sleep will give a bit more detail.
>>
>>     For fun, you can do a loop in the master script that that just calls the
>>     launch script (same one) over and over and that pulls a conf string based
>>     on the param passed
>>
>>     master:
>>
>>     #!/bin/bash  (I always spec /bin/bash so it won't fubar under a reset link
>>     to csh or <shudder>zsh)
>>     # master script
>>     MINNING=<path to mining script>  (this is chmod +x)
>>     miners=4
>>     for i in $(seq 1 ${miners})
>>     do
>>       ${MINNING} ${i}
>>     done
>>     tail -f <path to logs>/miner*.log
>>
>>
>>     ---------------------------
>>
>>
>>     The MINNING script is generically:
>>     #!/bin/bash
>>     # this runs the actual minning process
>>
>>     which_one=$1
>>
>>     case $which_one in
>>       1)       graphics_param='string of crap for card 1'
>>                 log_file='path to output log/miner'${which_one}'.log'
>>                 ;;
>>       2)       graphics_param="second string of graphics crap'
>>                 log_file.....
>>                 ;;
>>     ...
>>     esac
>>
>>     # Now run the script with all the params
>>
>>     <miner binary name> ${graphics_param} ${log_file} &
>>
>>     return 0
>>
>>     ------------------------------
>>
>>     So if you get more graphics cards, edit the script and add a new case line
>>     and edit the master and up the counter.
>>
>>
>>
>>     On Wed, Apr 17, 2013 at 9:35 PM, Ron Frazier (ALE)
>>     <atllinuxenthinfo at techstarship.com
>>     <mailto:atllinuxenthinfo at techstarship.com>> wrote:
>>
>>         Scott,
>>
>>         I want to thank you for the very detailed response you gave.  This
>>         gave me enough information to solve the problem.  I thought I'd share
>>         the solution in case others might benefit from it.  What I think is
>>         useful, is the way I've stacked multiple scripts together and attached
>>         them to an icon.  This can be handy whether you're mining or not.
>>
>>         Here is a simplified version of the MINER1 script that runs the
>>         specific process for graphic card 1.  There will be a MINER2, 3, and 4.
>>
>>         #!/bin/bash -eu
>>         # script to start litecoin mining on the first graphic card
>>         cd ~/cgminer
>>         export -task-specific-stuff-
>>         ./cgminer -lots-of-special-parameters-for-gpu1-only-
>>         echo "Press enter to continue."
>>         read junk
>>
>>         I got the -eu part on the bash line from a book, which adds in some
>>         special error checking for bash.
>>         The last two lines force the script to pause before closing its window
>>         until you press enter.
>>
>>         For MINER2, 3, and 4, I've temporarily commented out all lines except
>>         the last two, so I can use them for testing.
>>
>>         Here is the START-MINERS script, which starts each individual miner
>>         script, in its own separate window, with it's own separate geometry
>>         and title.
>>
>>         #!/bin/bash -eu
>>         # program to start all mining scripts
>>         cd ~/mining-scripts
>>         # commands to start the first miner
>>         mate-terminal --geometry=70x4+1800+100 -t "Miner 1" -e ./miner1 &
>>         # commands to start the second miner
>>         mate-terminal --geometry=70x4+1800+250 -t "Miner 2" -e ./miner2 &
>>         # commands to start the third miner
>>         mate-terminal --geometry=70x4+1800+400 -t "Miner 3" -e ./miner3 &
>>         # commands to start the fourth miner
>>         mate-terminal --geometry=70x4+1800+550 -t "Miner 4" -e ./miner4 &
>>         echo "Press enter to continue."
>>         read junk
>>
>>         I have to use mate-terminal to activate Mint's terminal emulator.  The
>>         --geometry option (mentioned by both you and Brian) sets the window
>>         size for each MINERx script as well as a location so they all stack up
>>         on the right of my monitor.  The -t option specifies a unique title
>>         for each window.  Each MINERx program is started with the "&" command
>>         (also mentioned by you and Brian) so the master script keeps on going
>>         without waiting.  For some reason, I had to put the read command at
>>         the end of the START-MINERS script or the sub scripts never kick off. 
>>         I have no idea why.
>>
>>         I'd rather have a delay in the START-MINERS script so it would
>>         terminate without me pressing a key.  I haven't found out how to do that.
>>
>>         Finally, here's how I created an icon in GNOME to kick off the whole
>>         enchilada.
>>
>>         Right click on the desktop, click create launcher, select type:
>>         application, name: Start Miners, command: mate-terminal -e
>>         /home/ron/mining-scripts/start-miners, click OK.
>>
>>         Now, upon clicking this icon, it starts the start-miners script, which
>>         in turn starts MINER1, 2, 3, and 4, which in turn post 4 terminal
>>         windows on the screen and run the processes I want them to.
>>
>>         Very cool.
>>
>>         Thanks again for the help.
>>
>>         Sincerely,
>>
>>         Ron
>>
>>
>>
>>         On 4/17/2013 3:36 PM, Scott Plante wrote:
>>>         (answers inline)
>>>
>>>         > So, my first question is how do I set up a basic script file 
>>>         > with these commands in it.  I can fill in all the details later.
>>>         > 
>>>         > cd ~/cgminer
>>>         > export .....
>>>         > ./cgminer .....
>>>
>>>         Yes, you can do that. You'll need to set the execute bit using "chmod
>>>         +x miner1" or "chmod 755 miner1" or similar.
>>>
>>>         Usually you'll want to put this as the first line of your script:
>>>         #!/bin/bash
>>>         But it's not strictly necessary. It comes into play usually when
>>>         you're in one shell and the script is written for another, but it's a
>>>         good habit to get into.
>>>
>>>         > Also, how do I put comments in the file?
>>>
>>>         bash and most Linux shells use # to start comments. Anything after
>>>         the pound on a line is a comment.
>>>
>>>         > Now, as I said, the command for each graphics card 
>>>         > is unique.  So, I need to set up a MINER2, MINER3, 
>>>         > and MINER4 scripts, which are customized for the 
>>>         > individual graphics cards.
>>>
>>>         Well, you could make one script that takes a parameter and use
>>>         something like:
>>>         if [ "$1" = 1 ]; then
>>>           #miner1 specific commands...
>>>         elif [ "$1" = 2 ]; then
>>>           #miner2 specific commands...
>>>         #and so on...
>>>         elif [ "$1" = --all ]
>>>           #I'll come back to this
>>>         else
>>>           echo "USAGE: $0 [--all|miner-num]" 1>&2; exit 1
>>>         fi
>>>
>>>         You could also use "case" instead of if/elif/else/fi and that might
>>>         be cleaner. As always, there's more than one way to skin the cat.
>>>
>>>         > Finally, I want to create a master script to start all the other 
>>>         > 4.  Here's the trick.  I want the master script to start each of 
>>>         > the sub scripts in its own window and continue executing 
>>>         > commands in the master script.  I don't want the master 
>>>         > script to hang waiting for MINER1 to exit before executing
>>>         > MINER2, and so forth.
>>>         > 
>>>         > Let's say that the master script is called START-MINERS.
>>>
>>>         Well, do you really need separate windows or do you just need
>>>         parallel execution? Generally, you can use the ampersand (&) at the
>>>         end of a line to run that command in the background. If the miner
>>>         commands have output you want to view on the screen, you can start an
>>>         xterm to open a window for each one. I use kde, so I tend to use
>>>         konsole but for this purpose xterm will work or you can check the
>>>         options for whatever terminal window you like to use. In the above
>>>         script under "--all" where I said I'd come back to it, you could put:
>>>
>>>         for miner in 1 2 3 4
>>>         do
>>>           xterm -e $0 $miner &
>>>         done 
>>>
>>>         dollar-zero is the current script so you're re-running the current
>>>         script once each for 1, 2, 3, 4. Although since it's just 4 you might
>>>         just repeat the command four times instead. Or go the other way and
>>>         have a config file that defines each miner instance, but that seems
>>>         like a down-the-road enhancement. 
>>>
>>>         > Finally, I want to kick off the whole thing from one icon on
>>>         > the desktop which triggers START-MINERS which triggers
>>>         > MINER1, 2, 3, and 4.  I don't care if the master script has a 
>>>         > terminal window left on the screen or not when it's done.  
>>>         > However, when it's finished, there should be 4 active terminal 
>>>         > windows on the screen mining on 4 separate graphics cards.
>>>
>>>         In kde, you can right-click on the desktop, select "Create new->Link
>>>         to application" and then fill in the boxes. I imagine you can do
>>>         something similar in Gnome.
>>>
>>>
>>>         > Even better, I'd like the windows to automatically size themselves 
>>>         > to a certain size and stack up all in a column on the monitor.  Better
>>>         > still, would be to have the whole thing auto start when booting.
>>>
>>>         xterm and most X Windows programs accept certain standard options,
>>>         which you can see by running "man X". In this case you can specify
>>>         the size and location with "-geometry". So for example:
>>>
>>>         xterm -geometry 80x30+10+10 -e $0 $miner &
>>>
>>>         as the xterm command. You could just specify 4 (or however miner
>>>         instances you have) separate xterm commands instead of the "for"
>>>         loop, or you could also do math in the shell based on the miner
>>>         number. That might be more trouble than it's worth, though. 
>>>
>>>         As to starting automatically on boot, you have the issue of needing
>>>         to be logged in to start the xterms. You'd probably want to send the
>>>         output to a log file for the actual miner commands, then when you
>>>         login you could have a command that starts the xterms with "tail -f
>>>         logfile" instead of actually running the miners directly. In this
>>>         scenario you'd create an /etc/init.d script to start the actual miner
>>>         processes. You probably want to see where you can get with the above
>>>         before jumping into that.
>>>
>>>         > If you can help me with all or part of this puzzle,
>>>         > I'd greatly appreciate it.  Thanks in advance.
>>>         >
>>>         > Sincerely,
>>>         >
>>>         > Ron
>>>
>>>         Well, that should get you started anyway. I typed these commands
>>>         mostly off the top of my head, so there may be some "miner" errors
>>>         (ha ha). You will find the docs for the if/then/elif/else/fi and
>>>         case/esac under "man bash". You can man xterm for details on other
>>>         options. Reply with more specific questions as you get into it, if
>>>         you need to.
>>>
>>>         Scott
>>>
>>>
>>>
>>>         -- 
>>>         Scott Plante, CTO
>>>         Insight Systems, Inc.
>>>         (+1) 404 873 0058 x104 <tel:%28%2B1%29%20404%20873%200058%20x104>
>>>         splante at insightsys.com <mailto:splante at insightsys.com>
>>>         http://zyross.com
>>>
>>
>>
>>         -- 
>>
>>         (PS - If you email me and don't get a quick response, you might want to
>>         call on the phone.  I get about 300 emails per day from alternate energy
>>         mailing lists and such.  I don't always see new email messages very quickly.)
>>