everything wrong with free software

 "obedience breeds foolishness"

### avoid-this-snippet other pages: => the-wonders-of-modularity.html the-wonders-of-modularity *originally posted:* aug 2021 i tried to make this as innocuous as possible: ``` #!/bin/ksh #### license: creative commons cc0 1.0 (public domain) #### http://creativecommons.org/publicdomain/zero/1.0/ c=0 ; for each in $(find . -type d | grep -v "\ ") ; do cd $each ; p="$(find . -type f | wc -l)" ; r="$(find .. -type f | wc -l)" ; if [ $p == 1 ] && [ $r == 1 ] ; then echo mv * .. " # $(pwd)" ; c=$(($c+1)) ; fi ; done ; cd /home ; echo "$c files moved" ``` what this does is move files around, per specific conditions. there are several ways this can be tweaked to do related tasks, but the main goal of this is the following: 1. get a list of all subfolders (dont bother with ones that have spaces in the names) 2. in each subfolder, if there is only one file from this path (including further subfolders) and nothing (just the same file) via the parent folder... 3. then move everything to the parent folder why would i want to do that? ive worked with a LOT of inexpensive, old computers. ive worked with a LOT of gnu/linux distros, and ive moved to bsd. when i install to a new system, i will often simply move everything to another machine prior to installation. doing this has created a lot of semi-duplicate filesystems. ive made a LOT of different tools for dealing with that. tools-- not products. a few are interesting enough to package, but mostly its a process (not a product). for me, fig is a great language for dealing with this stuff. sometimes i use python, and sometimes i use ksh. not bash, ksh. i was just talking to someone who was telling me that ksh is easier (fewer features and fewer gotchas). i told him i had just written an article about that, and i feel almost cheated by gnu bash (there are still a couple features i like, but i dont have much use for gnu bash really). seriously, the amount of time i spent coddling and learning way after way to get AROUND all of the "features" it has, i just assumed it was the easiest because SO MANY PEOPLE use it even when starting out. ksh would have been a lot easier to use and learn-- it does what i EXPECT bash to do, but it does it with fewer gotchas. so now i tell people that bash is a bad thing. but if it really suits your purposes, then use it. i simply dont recommend you do. its on the verge of being an npi, and gnew seems to value stability and simplicity more than bash does. ive ranted about this recently, so lets get back to the point of this snippet-- which you should not use unless youre CERTAIN what it does and youve experimented with it on a machine with nothing important on it. that said, its probably safe. im not willing to be super confident with a new snippet like this. ive been using it a lot today and so far, i get a lot of errors (which make perfect sense, actually) but when i go back to look at the actual effect of the script, it seems to be doing essentially what i intended it to. i could make it more complex, cover more non-standard uses, but this is meant to help turn manually doing hundreds of moves into manually doing far fewer moves. its not meant to do it all for me-- so i get away with using a lot less code. it checks the current folder for the number of (-type f) files, and the parent folder-- to see if both have exactly 1 (in other words, if the parent folder does not have more than the current folder-- which means its empty). we are talking about files here-- not folders, so if we are checking for just one file (which we are) then: ``` p="$(find . -type f | wc -l)" ; r="$(find .. -type f | wc -l)" ; if [ $p == 1 ] && [ $r == 1 ] ; then ``` if p is 1 and r is 1, we know that there is 1 file in r (the current folder and subfolders) and 0 files in the parent folder. p (being the parent folder) always includes r in its sum, so we know the largest file count that can be in the parent folder by itself is p - 1 (if 1 file is in a subfolder). its annoying when its explained it this way, (sorry about that) but this was intuitive to me when i was coming up with it. ### the point after all those semi-duplicated, semi-merged, semi-deduplicated filesystem migrations, i will often find (thanks to a graphical or markup-producing tool i have) that theres a single file keeping me from removing a string of otherwise empty folders, like so: ``` folder1/file.txt folder2/some/other/folder/with/no/other/files/except/this.htm folder3/file.gif folder3/somefolder/somefile.txt ``` i have too many instances of this sort of thing: ``` folder2/some/other/folder/with/no/other/files/except/this.htm ``` and what i want, is: ``` folder1/file.txt folder2/this.htm folder3/file.gif folder3/somefolder/somefile.txt ``` notice that folder3 wont improve because theres already ONE file in folder3. thats the design. i want it to mess with as few things as possible. but so far this has moved hundreds of files for me. and i still have the same files-- theyve simply moved up, so i can delete the extra folders that are empty with rmdir. could i make a more elegant version of this? yes. but rather than spend more than an hour writing a perfect solution, i wrote a simple one so that i could get back to what i was doing. it wont fix everything. but on top of that, it hasnt given me an extra thing to fix. im not saying this is elegant, im saying this is simple and effective. it does most of what i want, and costs practically nothing. a solution that costs more in terms of effort would do more. then however, i would have to put aside other things im working on. its not as important as that. you are advised to avoid this snippet, but you are free to decide for yourself if you want to experiment with or adapt it to your purposes. to make this work, there are two things you should disengage. the first one is more important, because unlike the other one i have no idea what will happen if you leave it there. ### BE CERTAIN YOU REMOVE THIS ONE: ``` " # $(pwd)" ``` it is a quoted comment following (part of) a mv command. i have no idea what happens if you remove the echo and leave this. ### ONLY THEN, remove this: ``` echo ``` with these commands in place, youll get an idea of what the snippet is planning to do. however, the preview cant predict the future, because folders that are there WHEN NOTHING ACTUALLY MOVES are not necessarily there when mv actually moves instead of echoing. in other words, this does not generate a static script-- you want to actually run it so that each check of p and r is up to date (after each move). but the " # $(pwd)" lets you get (as much as possible) a list of things that are likely to be moved. you should not rely on the preview. the reason i cant tell you what happens if you leave " # $(pwd)" but remove echo, is i didnt design it to be used that way and i dont presently have a realistic setup i want to try it on. it might do nothing. even if you use it as intended, i trust my own setup (but not yours) to this code. to say the least, there is no warranty. => https://wrongwithfreesw.neocities.org