Return to “Announcements”

Post

Re: The End

#317
Shados wrote:
Sun Jun 16, 2019 8:03 pm
Spoiler:      SHOW
Silverware wrote:
Thu Jun 13, 2019 7:26 pm
Just to show how my code looks when being written for a production environment.
Spoiler:      SHOW

Code: Select all

args=""
if [ -n "${MASTER}" ]; then args="${args} -S ${MASTER}"; fi
if [ -n "${CLIENT}" ]; then args="${args} -C ${CLIENT}"; fi
if [ -n "${POLICY}" ]; then args="${args} -k ${POLICY}"; fi
if [ -n "${POLICYTYPE}" ]; then args="${args} -t ${POLICYTYPE}"; fi
if [ -n "${AFTER}" ]; then args="${args} -s ${AFTER}"; fi
if [ -n "${BEFORE}" ]; then args="${args} -e ${BEFORE}"; fi
if [ -n "${NOCLOBBER}" ]; then args="${args} -K"; fi
## Start Restore of File(s)
if [ -z "${FILELIST}" ]; then
	log "Restore Started for ${FILE}"
	${BPRESTORE} ${args} -L ${TMPFILE} -w ${FILE}
	# '-w' is used so that this sciprt will only move on ONCE the file has finished (or failed) restoring
	RET=$?
	log "Restore Finished for ${FILE}"
else
	# Rename only works as a filelist, so we include the feature here
	if [ -n "${RENAME}" ]; then args="${args} -R ${RENAME}"; fi
	log "Restore Started for Multiple Files"
	${BPRESTORE} ${args} -L ${TMPFILE} -w -f ${FILELIST}
	# '-w' is used so that this sciprt will only move on ONCE the file has finished (or failed) restoring
	RET=$?
	log "Restore Finished for Multiple Files"
fi
So that you can see the difference.
Pretty reasonable. Assuming it's being run on a vaguely-recent bash, I would suggest some changes:
  • Construct `args` by appending to an indexed array, not a string, like:

    Code: Select all

    args = (); args+=("-S" "${MASTER}")
  • Then, when calling `BPRESTORE`, expand `args` as an array to ensure each item is passed as a separate arg, like:

    Code: Select all

    ${BPRESTORE} "${args[@]}" ... 
  • Double-quote the other arguments you pass to `BPRESTORE`; even if you know a priori that they do not contain spaces or globs, that may no longer be true after you or someone else edits the script later, so you're still better off quoting them to prevent possible unexpected behaviour in the future.
  • The combination of those three changes clarifies the intent of the code, and prevents unexpected word-splitting changing what should be a single argument token into multiple tokens.
  • Start using shellcheck. Ideally, with editor integration.
Actually, thats something I never thought of, using variable expansion to deal with Args, will change in future versions.
This did go through one of the shellcheck variants, I forget which.
The quotes around the ${BPRESTORE} line are actually EXPLICITLY left out, because for some reason the application decides that the quotes means that that's actually a file and not a set of arguments, and then throws that to the netbackup server, rather than throwing the file list.
Removing the quotes made it work, leaving them there broke it. It was easy to resolve, just not perfectly correct. :3
°˖◝(ಠ‸ಠ)◜˖°
Image
qRogue v0.0.9
Post

Re: The End

#318
I definitely agree with the practice of quoting enthusiastically in shell scripts, even when it's not strictly necessary. My theory is always that accidentally using too much quoting will cause immediate problems which are easy to debug (removing the quotes, when necessary); whereas not enough quoting may very well work fine on your development data, and only break later (maybe much later), in ways which may be difficult to debug. Ditto with using curly braces around variable names even when not actually needed.
The quotes around the ${BPRESTORE} line are actually EXPLICITLY left out, because for some reason the application decides that the quotes means that that's actually a file and not a set of arguments
Yes, quoting a single variable "${args}" makes the whole thing a single argument; but IIRC bash arrays work like the standard $@ in which case quoting "${args[@]}" would be equivalent to having individually quoted each element of the array, just like "$@" does for the positional parameters.

(I'd be more certain of that, but I have a masochistic habit of trying to write all my shell scripts as portable /bin/sh scripts even when I don't need to, so I almost never use bash features...)
Post

Re: The End

#319
Employee 2-4601 wrote:
Mon Jun 17, 2019 4:31 am
I definitely agree with the practice of quoting enthusiastically in shell scripts, even when it's not strictly necessary. My theory is always that accidentally using too much quoting will cause immediate problems which are easy to debug (removing the quotes, when necessary); whereas not enough quoting may very well work fine on your development data, and only break later (maybe much later), in ways which may be difficult to debug. Ditto with using curly braces around variable names even when not actually needed.
The quotes around the ${BPRESTORE} line are actually EXPLICITLY left out, because for some reason the application decides that the quotes means that that's actually a file and not a set of arguments
Yes, quoting a single variable "${args}" makes the whole thing a single argument; but IIRC bash arrays work like the standard $@ in which case quoting "${args[@]}" would be equivalent to having individually quoted each element of the array, just like "$@" does for the positional parameters.

(I'd be more certain of that, but I have a masochistic habit of trying to write all my shell scripts as portable /bin/sh scripts even when I don't need to, so I almost never use bash features...)
You are correct, I use bash features so often I don't think I could write a portable /bin/sh script any more!

Code: Select all

sargs="a b c d"
aargs=( "a b" c d )

ls "$sargs"		# lists the single file "a b c d"
ls $sargs		# lists 4 files "a", "b", "c", "d"
ls "${aargs[@]}"	# lists 3 files: "a b", "c", "d"

ls ${aargs[@]}		# lists 4 files: "a", "b", "c", "d"
ls ${aargs[*]}		# lists 4 files: "a", "b", "c", "d"
ls "${aargs[*]}"	# lists 1 file "a b c d"
Post

Re: The End

#321
Victor Tombs wrote:
Fri Jun 07, 2019 2:22 am
Tycow wrote:
Thu May 02, 2019 7:30 pm
Yea, I'd be interested in getting a copy of the soundtrack as a consolation prize! :)
Maybe Josh intends using the soundtrack in some other, as yet, unannounced project, Tycow. ;)

Pure speculation on my part. :angel:
Maybe, but given his track record I'd still like a copy of the sound track as a separate thing... :)
Image LT Backer Number: 647 of 5449.
Post

Re: The End

#322
Tycow wrote:
Fri Jun 21, 2019 3:29 am
Maybe, but given his track record I'd still like a copy of the sound track as a separate thing... :)
I wouldn't argue with that, Tycow. There isn't much Josh can offer in a complete form but the soundtrack was delivered in full by François. I'd like the CD's but I'd settle for a quality download. :) :angel:
Post

Re: The End

#323
Victor Tombs wrote:
Sat Jun 22, 2019 12:55 pm
Tycow wrote:
Fri Jun 21, 2019 3:29 am
Maybe, but given his track record I'd still like a copy of the sound track as a separate thing... :)
I wouldn't argue with that, Tycow. There isn't much Josh can offer in a complete form but the soundtrack was delivered in full by François. I'd like the CD's but I'd settle for a quality download. :) :angel:
Yarp, would happily take a high quality download! Perfect for listening to while gaming. :)
Image LT Backer Number: 647 of 5449.
Post

Re: The End

#325
I agree, it's time to release everything. It has been 8 months, we have all waited patiently for the game's code to be released. Let us see it, no matter how ugly it is, some might be able to make sense of it and some small progress might be made. I would hate for a full year to pass and have to settle on the belief that this project has become vaporware.

I wish you the best Josh, and I do hope you let this awesome community work with the bones of your project.
Image
Post

Re: The End

#327
ResultsMayDiffer wrote:
Mon Jun 24, 2019 5:33 am
Hey Josh. Do me a favor and release the source code. Nobody is going to make a huge profit off your work you worry too much.
He's translating it all from spaghetti code into something that people not named Josh Parnell can mess with. Releasing the source code is completely pointless if it's too much of a mess for people to do anything with it. We were waiting years for LT, we can wait a bit longer for the source.
Image
Image
Post

Re: The End

#328
cuisinart8 wrote:
Mon Jun 24, 2019 11:22 am
ResultsMayDiffer wrote:
Mon Jun 24, 2019 5:33 am
Hey Josh. Do me a favor and release the source code. Nobody is going to make a huge profit off your work you worry too much.
He's translating it all from spaghetti code into something that people not named Josh Parnell can mess with. Releasing the source code is completely pointless if it's too much of a mess for people to do anything with it. We were waiting years for LT, we can wait a bit longer for the source.
I actually start to disagree.
Josh has a track record of not being satisfied with the results and postponing. Whatever he is doing now (I hope a nice job), this code is not anymore his 100% job.
So after many months he should just fulfill his promise and release the code. As is. Usable or not. Just deliver!
Now, today, without loosing one more minute on it.

This does not stop him to work on it and release a better version later on the road, if he wants to maximize the chances of somebody making something out of it.

But he should quit this bad habit of promising and not delivering. He is building a bad reputation!
I will most certainly not even look at the code, so my statement is not because I want it, but because he should learn to stand up to his promises!
Image
Post

Re: The End

#329
CSE wrote:
Mon Jun 24, 2019 12:23 pm
*snip*
That's another possibility, and given Josh's track record his perfectionist streak very possibly is kicking in again. We probably won't know until either he releases it or returns here for a quick update in another 6 months :3
Image
Image
Post

Re: The End

#330
cuisinart8 wrote:
Mon Jun 24, 2019 11:22 am
He's translating it all from spaghetti code into something that people not named Josh Parnell can mess with. Releasing the source code is completely pointless if it's too much of a mess for people to do anything with it. We were waiting years for LT, we can wait a bit longer for the source.
Hi you are wrong. Josh release the source code. It's going to be ugly and mostly unusable no matter how many hours you spend. Committing what there is to github or similar will make it a lot easier to work with, it's too easy to ignore for you right now. Nobody blames you for that. Just publish as is.

Online Now

Users browsing this forum: No registered users and 0 guests

cron