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

[Vadim Zeitlin]

On Sat, 13 Jun 2020 13:13:50 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

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

 It would seem to me that using more semantic names could be useful even
during the (unavoidably messy) initial process, but this is up to you, of
course.

GC> >  This assumes that the sort order of these files is important, i.e. that
GC> > "40" is necessary, but, to be honest, I'm not totally sure about this as I
GC> > couldn't actually find where are these files sorted by their names, so
GC> > maybe the "40" part is not indispensable neither?
GC> 
GC> In /etc/grub.d I see
GC>   00_header
GC>   05_debian_theme
GC>   10_linux
GC> and so on. There, as here, the numeric prefixes aren't essential,

 Just for the record: in the case of GRUB, and many other *.d directories,
they definitely are essential as the files are read in their alphanumeric
order and the latter files override the earlier ones. I.e. the file names
define the order. This may not be the best idea, but it's very much a
standard one and a widely used one, at least in Debian.

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

 Again, it just seems to me that refactoring functions inside the same file
would be simpler than refactoring across files, which is why I proposed
doing it like this, but if you prefer working with multiple files, this is
not a problem, of course.

 In any case, good luck once again with finishing this!
VZ

pgpvdtpTj6vdF.pgp
Description: PGP signature