lmi
[Top][All Lists]
Advanced

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

Re: [lmi] [lmi-commits] master 0d823ab 11/12: Merge 'lmi_setup_41.sh' in


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 0d823ab 11/12: Merge 'lmi_setup_41.sh' into 'lmi_setup_40.sh'
Date: Sat, 13 Jun 2020 13:13:50 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 2020-06-13 12:03, Vadim Zeitlin wrote:
> On Thu, 11 Jun 2020 20:58:34 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC>     Merge 'lmi_setup_41.sh' into 'lmi_setup_40.sh'
[...]
>  I wanted to ask this since quite some time, and this looks like as good an
> opportunity as any, so I'm finally going to do it: could it be helpful to
> use some readable suffixes for these files? Right now I have no idea what
> does lmi_setup_40.sh do, nor what the late lmi_setup_41.sh did, and while I
> probably can find it out by reading their contents, wouldn't it be useful
> to use a name such as lmi_setup_40_wine_user.sh or something like that for
> it?

Eventually, sure. The problem is that I started with a single script
that was just a monolithic series of commands in an order that had
evolved rather than being designed, and am still in the process of
refactoring it. For example, 'schroot' automatically sets up a root
user only, so a normal user must be created, so I called 'useradd';
then I wanted my user to have 'zsh', so I called 'apt-get install zsh'
and then called 'chsh' for each user, probably all in close proximity;
then I wanted my customary '.zshrc', so I downloaded and installed
that, probably in some other place in the script...and so it went.
I didn't start with a structured list of all necessary steps because
I didn't know all those steps or their structure beforehand.

Now I want to set up multiple users, which would be as simple as
 - set_up_user $one_and_only_user
 - for z in multiple_users; do set_up_user $z; done
if I already had the ideal design...but I don't, so I'm trying to
improve the design one step at a time.

For now, there's some documentation in the "| tee /dev/tty" line at the
bottom of each script:

  lmi_setup_40.sh:
-echo "$stamp $0: Installed 'wine'."  | tee /dev/tty
+echo "$stamp $0: Configured 'wine' for '$NORMAL_USER'."  | tee /dev/tty
  lmi_setup_41.sh:
-echo "$stamp $0: Configured 'wine' for '$NORMAL_USER'."  | tee /dev/tty

Formerly, 'lmi_setup_40.sh' basically just called 'winecfg'
(though "Installed 'wine'" isn't the best description of that),
and 'lmi_setup_41.sh' created symlinks like:
  #   /opt/lmi/     becomes ../../../../../../../opt/lmi
but now those things are done together.

>  This assumes that the sort order of these files is important, i.e. that
> "40" is necessary, but, to be honest, I'm not totally sure about this as I
> couldn't actually find where are these files sorted by their names, so
> maybe the "40" part is not indispensable neither?

In /etc/grub.d I see
  00_header
  05_debian_theme
  10_linux
and so on. There, as here, the numeric prefixes aren't essential,
as long as the proper order is expressed somewhere, by some means;
but they do indicate an ordering. Expressing that ordering in the
'lmi_setup*' scripts' names isn't necessary because they're called
in a hardcoded order; however, if they need to be called in any
order that isn't ascending, then that helpfully reveals a problem.

For example, in some recent series of experimental changes, I
found that I needed to invert the order of the #21 and #24
scripts after a certain refactoring...which showed me that what
I really needed was to split out a new #29 step first, for the
part of #21 that turned out to depend on #24.

> Of course, we can go
> further continuing on the same road and even ask the question of whether we
> really need all these different files instead of just different functions
> inside the same files, but for now I'd really be happy enough to just have
> some indication of what each of these files does in their name, as this
> would make it much simpler for anybody but their author to understand
> what's going on, if they ever need to do it -- and perhaps it would be even
> helpful to you too?

Yes, perhaps refactoring everything into shell functions rather than
shell scripts would be better, especially as the number of scripts
increases (and this commit is probably the only one where that number
has decreased). But that change can be made mechanically once the
design has stabilized.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]