Knowledge Base

Overview

My bgscripts package in version 1.1-27 and before was installed in /usr/bgscripts. The more I thought about it, and the more I read the spec for FHS 3.0 (filesystem hierarchy standard) (PDF), the more I realized it should actually be in /usr/share/bgscripts. Moving the files in the build directory was easy.

Wrapper script

But despite my symlinks in /usr/bin, which were easy to update, I have many, many hard-coded pathname calls of my scripts everywhere. So to mitigate the problem, I wrote a fancy wrapper script for regular scripts, including bup, send, bgscripts.bashrc, rdp, and treesize. I needed to send myself a message with the various information about what script called the old location. I picked send.sh because that's what it's for-- sending emails. I slapped in a bunch of diagnostic information and wrote a call to the new location. `

!/bin/bash # Wrapper at legacy location for bgscripts. Sends alert and then

continues the process. # DETERMINE LOCATION OF FRAMEWORK while read flocation; do if test -x ${flocation} && test "$( ${flocation} --fcheck )" -ge 20161212; then frameworkscript="${flocation}"; break; fi; done <&2 && exit 4 . ${frameworkscript} || echo "$0: framework did not run properly. Aborted." 1>&2 ### CUSTOM WRAPPER BEGINS HERE pwd="$( pwd )" psout="$( ps -ef )" parentprocess="$( ps -ef | grep -iE -- "${thisppid}" | grep -viE -- "grep.-iE.--" )" /usr/share/bgscripts/send.sh -hs "bgscripts alert ${server}: ${scriptfile}" bgstack15@gmail.com <<EOF ----- Description ----- This alert means that script "${scriptfile}" was called, and you need to fix it because /usr/bgscripts/* has been deprecated and will be removed in a future version. ----- Debug info----- pwd: ${pwd} Scriptdir: ${scriptdir} Scriptfile: ${scriptfile} All parameters: $@ Server: ${server} Now: ${now} Thisos: ${thisos} Thisflavor: ${thisflavor} Thisppid: ${thisppid} Parent process: ${parentprocess} ----- Process list ----- ${psout} EOF ### CALL NEW LOCATION /usr/share/bgscripts/${scriptfile} "${@}" ` So if something of mine calls /usr/bgscripts/bgscripts.bashrc, this wrapper script will throw an email alert, and then redirect the script call so workflows are not interrupted! The very first production use of the wrapper script was when I logged onto my test Ubuntu box to conduct a deep-dive search (more on that in the next heading) of scripts that call framework.sh. I got an email right away, saying I had dot- sourced the bashrc script. Looking at the diagnostic info, I was reminded that I tended to hardcode into my ~/.bashrc the call to /usr/bgscripts/bgscripts.bashrc. I have now updated that to point to /usr/bin/bp, so in the future it will point to wherever I want it to. However, I seriously doubt the location will change now. My package is now FHS 3.0 compliant, and I don't want to break that.

Deep dive search

So, I wanted to conduct a deep-dive search of all shell scripts (defined by me as everything ending in .sh, because I almost always use the extension) on all systems that refer to framework.sh, which is going to be the big hangup. So I whipped up this oneliner. sudo updatedb; locate .sh | grep -iE "\.sh$" | grep -viE "\/usr\/src|\/usr\/share|\/usr\/lib|\/home\/.*\/rpmbuild/|\/home\/work\/.*clean" | xargs grep -iE "framework\.sh" Now, an reading of my code shows that many of my scripts do a lookup for framework.sh in various locations, including ./framework.sh, ~/framework.sh, /usr/local/bin/framework.sh, and so on. You can observe this pattern in my wrapper script in this post. So the serach will catch those, but I will recognize those blocks of code because they are just the filename on a separate line (in a here- doc) and as long as I see the /usr/libexec/bgscripts/framework.sh final resting place of framework, I'll be satisfied.

References

Weblinks

1. Filesystem hierarchy standard 3.0 http://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
2. FHS 3.0 in pdf http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf
3. Here document https://en.wikipedia.org/wiki/Here_document