2 Welcome, adventurous script user.
4 These are the handiest commands available in the Feisty Meow scripts.
5 Note that each script is expected to be self-documenting. Try running it
6 with a "--help" flag (or with no parameters in some cases) to print the
7 built-in docs. At worst, you may have to read the script (that is a
8 "documentation fail" on our part; please let us know).
10 setup and loading commands
11 ==========================
13 + read "readme.txt" in the top of the feisty meow codebase, or
14 + read it online at: https://feistymeow.org/feisty_meow/readme.txt
16 generally useful commands
17 =========================
20 reports similarly to the good old system "pwd", but translates the $HOME
21 variable into the '~' name. e.g., if you're fred in /home/fred/turnips
22 and you run 'pwd', then it will print: ~/turnips
25 take inventory. prints out some time and relative dimension in space
26 information and shows the current directory's contents.
28 dir or l (lower-case L):
29 show the directory with a "summing" feature that calculates the full size
30 consumed by all files in the listing, with somewhat esthetic output.
33 like 'dir' but also includes hidden files (e.g. those starting with a dot).
36 the standard ls command (not the summing directory), but with ls colors
40 invoke "safedel" feature to remove the files specified. this archives the
41 deleted files in "$TMP/zz_safedel_keep" and writes a report of the deletion
42 history in "$TMP/zz_safedel_report.txt".
45 update the feisty meow codebase from its origin and run the reconfigure
46 script to update the current user's feisty meow configuration.
48 note: currently there is no "empty the trash" function aside from running a
50 # \rm -rf $TMP/zz_safedel*
51 the backslash forces bash to run the "rm" tool from the path rather than
52 using the feisty meow alias. a trash flushing feature is planned for the
55 revision control commands
56 =========================
58 all revision control commands bring up the editor in the EDITOR environment
59 variable when creating commit messages. you need to actually save and quit
60 from that editor when you're done writing your commit message.
62 here's a guide to writing good commit messages:
63 + https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
66 the first suite of commands takes a list of directory names as parameters and
67 then operates on those names.
71 does a simple update (or pull) of the repository paths provided on the
72 command line. this will only get things from the main origin that the
73 repository is hooked up with, so it is super quick compared to the next
77 update the repositories provided on the command line by "puffing them out",
78 which means that the upstream repositories that feed the local one will be
79 synched up with it. this is quite important to do when a git repository has
80 multiple branches, since unmerged changes upstream can really snarl up your
81 checkin. this is basically a heavyweight version of rgetem.
84 checks in the list of repositories passed on the command line. in git
85 parlance, this adds all modified or untracked files, then commits all
86 changes in the repository, and finally pushes up the changes to the remote
87 online repository. before doing the checkin, this will do a full "rpuffer"
88 update on the repository to ensure that there are no unmerged upstream
89 changes that could cause problems later.
92 the next suite of commands uses the REPOSITORY_LIST environment variable as
93 the set of revision controlled folders to operate on. the feisty meow scripts
94 automatically add the feisty meow top-level (the apex) to this list to ensure
95 that updates are received when available.
99 update all repositories in the REPOSITORY_LIST from their upstream remote
103 puffs out the REPOSITORY_LIST items to merge upstream changes.
106 checks in all changes in the REPOSITORY_LIST to their remote repositories.
109 some assorted other revision control commands:
113 shows the current branch that is checked out.
115 this command will move your feisty meow codebase to the development branch:
116 pushd $FEISTY_MEOW_APEX; git checkout dev; popd
118 and this command will get you back onto the mainline branch:
119 pushd $FEISTY_MEOW_APEX; git checkout master; popd
121 =============================
122 the site avenger script suite
123 =============================
125 the site avenger tools (inherited from the avbash project) are commands for
126 managing web sites. these scripts offer a lot of power to the developer, and
127 of course that comes with great responsibility...
129 the site avenger scripts are configured by "app" files stored in the "config"
130 directory (in $FEISTY_MEOW_SCRIPTS/site_avenger/config). the scripts
131 seek out a config file named after the application, e.g. they look for
132 "winterportlibrary.app" if the application name is "winterportlibrary".
133 the basic config file "default.app" is used for any application that is unknown
134 in the config directory. any of the variable definitions provided in
135 default.app can be overridden to change how the applications, and associated
136 web site and domain, are configured. see "mapsdemo.app" for an example of
137 overriding the domain name for the mapsdemo application.
140 establishes permissions and ownership to make the virtual machine and its
141 services behave properly. if something goes wonky, try running this script.
142 this script is also the main vehicle for delivering configuration changes
143 to the cakelampvm. we are trying really hard to never release a version 2
144 of the vm, since we can patch it as needed using the revamp script. let's
145 see how well that works out...
148 brings up an application or web site from scratch (potentially) by creating
149 an appropriate domain name, writing a basic apache site config file, pulling
150 the application from a git repository, and "powering up" the application via
151 composer. this is most powerful and effective on php sites, but can also be
152 used for other types of websites. note that this, and all of the scripts
153 here, are heavily biased for site avenger based development at saco designs.
154 to make these scripts truly your own, write configuration files (see above)
155 that define the proper folders and repository for your applications.
158 takes down a site previously brought up by the standup command. this just
159 eliminates the domain and the apache site though; the code is left in place
163 similar to standup, but just gets the application source out and powers it
166 (note: automatic database configuration and inflation is in the pipeline for
167 the powerup command, but is not ready yet.)
170 updates the avcore portion of a site avenger application. this command can
171 accept an application name within which to update, or it can auto-pick the
172 applicatin for you from the available checked out ones in ~/apps (the default
173 storage folder for all site avenger style sites).
176 updates the entire checked out repository for a site avenger application.
177 supports app name on the command line, or auto-picks the app.
180 checks in the source code and other site assets for a site avenger app.
181 supports passing an app name on the command line, or auto-picks the app.
184 updates satis for a site(?).
186 note: satis-refresh is the one site avenger command that hasn't been "feisty meowicized" yet.
188 lower level scripts used by site avenger scripts
189 ------------------------------------------------
191 add_domain and remove_domain: (from system script collection)
192 adds (or removes) a DNS domain to the bind9 configuration. the domain
193 tools, are very sensitive to any edits within the chunks of code they have
194 written. when it comes time to remove the domain again, the script will eat
195 the number of lines it expects to find after the beginning of the domain
196 definition that it added. to avoid any issues, if you need to edit the bind
197 config files, be sure to do it way above or way below the auto-generated
200 add_apache_site and remove_apache_site: (from system script collection)
201 creates (or removes) an apache compatible site definition. this will rely
202 on the site's domain previously having been added to the DNS.
204 note: currently we only implement the http site, but we're planning to add https support via self-signed certificates soon.