_ 2013MAY01 EDIT: _ Changed the order of the arguments, according to the first beta. When executed with no arguments, a simple help is displayed. The arguments are increasingly optional, so it is possible to provide just the "pmagic-extracted" path and the script should work, asking confirmation from the user._ First beta attached to post #12, reply #11._ Beta2 attached to post #152013MAY13 EDIT:_ Beta3 attached to post #222013JUN25 EDIT:_ pm2ubcd2013JUN25 attached to post #432013JUL29 EDIT:_ pm2ubcd2013JUL29 attached to post #44

I am seeking help here to put together a pm2ubcd.sh script to customize UBCD with an updated version of PMagic. Since PMagic releases are much more frequent than UBCD's ones, this should simplify the task for users, in a similar way as other scripts in UBCD. If it works as expected, Victor can hopefully add it to the next release of UBCD.

Here are the minimal conditions and goals:

_ The script would be located under

ubcd-extracted/ubcd/tools/linux/pm2ubcd/

, named

pm2ubcd.sh

.

_ The task of downloading and extracting the content of (Pmagic's and UBCD's) ISO images is up to the user.

_ The script should not care about the specific version or variant of PMagic. The user might want to use an older version of PMagic, or a newer one, or a different variant (i586, i686, x86_64).

_ The script should work on UBCD v5.2.1. Older versions of UBCD won't be supported by the script.

_ Similarly to other scripts in UBCD, the arguments needed by the script would be:13_ "iso_filename=" parameter (to modify PMagic's syslinux.cfg);21_ Path where the content of the PMagic ISO image is located (already extracted by the user);32_ Path where the content of UBCD is located (already extracted by the user).

There could be an alternative way to the first argument. Instead of the user having to provide the "iso_filename=" argument, it could (potentially) be read from other files in "

ubcd-extracted

". For the time being, I'm inclined to request this parameter from the user.

_ The script should:

1_ Delete the prior squashfs PMagic file(s) such as

Code:

ubcd-extracted/pmagic/pmodules/PMAGIC_*.SQFS

Any other (modules, scripts, personal, configuration) files are not to be touched.

Yes, I am thinking about this too. Again, the conditions I mentioned above are "minimal". Changing the version in main.cfg is not critical regarding the functionality, but indeed it should be considered. One alternative possibility would be for Victor not to include the version number of PMagic in main.cfg.

In case the version "must" be corrected in main.cfg, it would be taken from the SQFS file name.

The correct replacement of the version number in main.cfg might be "trickier" than the other "sed" substitutions. Any other part of the new pm2ubcd.sh script would act on

ubcd-extracted/pmagic/

or down the path tree, but main.cfg is another story (and it might contain other customizations too).

The "easier" way would be if Victor would consider not specifying the version of PMagic in main.cfg, specially since the "version" (date) is already included in

#!/bin/sed# if the filename is hard-coded in the sed scripts|^\(APPEND /pmagic/bzImage initrd=/pmagic/initrd\.img [^\r\n]*\)$|\1 iso_filename=ubcd521.iso|g

Code:

#!/bin/bash# if the filename is stored in a variable in a shell scriptISO_FILENAME=ubcd521.isosed -e "s|^\(APPEND /pmagic/bzImage initrd=/pmagic/initrd\.img [^\r\n]*\)\$|\1 iso_filename=${ISO_FILENAME}|g"

The UI substitution is unnecessary.Regarding the Fn substitution, what's wrong with the code I posted before?

Quote:

Code:

#!/bin/sed# if the filename is hard-coded in the sed scripts|^\(APPEND /pmagic/bzImage initrd=/pmagic/initrd\.img [^\r\n]*\)$|\1 iso_filename=ubcd521.iso|g

No, the desired "iso_filename" is an argument of the script, to be provided by the user from the command line (see conditions in OP).

Also, the specific kernel MUST not be part of the substitution, so the script can deal with any PMagic variant ("bzImage*"). My suggested code (in the OP) regarding the addition of "iso_filename" is not finished because it doesn't consider (yet) the command line argument input. It just searches " initrd=/pmagic/initrd.img " (with initial and ending space characters), and adds to it the "iso_filename" kernel argument.

I'd rather not search for entire lines (starting from "append" in this particular case) as in your suggested code, because searching for the minimal necessary expression covers more potential future changes in PMagic's syslinux.cfg (which are not under our control).

Quote:

Code:

#!/bin/bash# if the filename is stored in a variable in a shell scriptISO_FILENAME=ubcd521.isosed -e "s|^\(APPEND /pmagic/bzImage initrd=/pmagic/initrd\.img [^\r\n]*\)\$|\1 iso_filename=${ISO_FILENAME}|g"

Any way to do this server side? I have now own my own VPS with some high specs, was wondering if its possible to take the UBCD and Pmagic, both latest versions, from download sources, and verify Hash, and then Merge them server side, then provide a download with Hash. I was thinking with PHP it would be possible, but would require advanced coding that's beyond my expertise.

It should be noted that "pwd -W" should be "enough" (no real need for changing "/" into "\"). In spite of what many users think, Windows, since several years ago already, is perfectly fine with slashes "/" for paths.

In any case, the suggestion is valid. I moved (up) the check that confirms whether the paths exist, so to be able to use "pwd-msys" to display paths "as expected under each respective OS".

I limited the "slash inversion" (to "\") under Windows for the main directory paths and for subdirectories that are displayed by themselves; the rest (in relative notation) will still show slash "/". The relevant paths, specially drive letters, are correctly displayed as expected by users, so the information provided by the script should be more clear now.

FWIW, in the editions I made for this beta2, I prioritized "plain language" rather than "elegant code" (ie. "echo blank spaces", over "echo horizontal tabs"). BTW, I tried to follow the same principle in sed editions.

I will change some of those comments, but I want to make clear that I *know* that I commented "too much" in the script, intentionally.

During the years, contributors come and go. When a change is needed and there is no knowledgeable developer around, "nothing" can be done. This type of comments (somehow repeating what is already "evident" and not really adding to the code) are not just unneeded but also unwanted by developers, but they help "common poor mortals" so to try to understand (the logic in the script) in case a change is needed in the future (or in customizations).

Regarding the double equal sign in tests, I'll change the one you pointed to and a second one too. This needs intentional error testing under different OS, just in case.

Quote:

@@ -161,9 +158,9 @@ : Make good use of command substitution (i.e. the backticks). This avoids the non-portable "echo -n" and makes the code cleaner.

Actually, I used "-or" (instead of "-o") because of the MSYS and CYGWIN ports in UBCD. Are you sure this is the right move?

Quote:

@@ -191,7 +188,7 @@ : This guide says it is better to use an explicit variable in 'read' rather than implicit.

Agreed. Changed.

Quote:

@@ -321,7 +318,9 @@ : Change the 'find' logic.

I had this kind of logic before, but it was giving me troubles. Have you already tested this change?

(I also suspect that this logic should be faster, but I gave up when I found problems, so it would be nice to go back to use it, if it really works under all relevant circumstances.)

Of course, the question of POSIX is relevant here too ("-not" and "-or").

Quote:

@@ -350,7 +349,7 @@ : "\1" in 'sed' can save you a few characters. (I tend to avoid "&" for whole regex match as it is not so portable as "\1")

Yes, the "\1" (and "\2"...) is used in several places in UBCD's scripts already. But this is (although, arguable) one example of prioritizing "plain language". The text to be repeated is not long, so "repeating" the text is not such a big deal (I know developers don't stand this anyway). When a "common poor mortal" reads the code as seen in the cfg file, it is easier to understand and to customize it. A user trying to understand the "\1" needs to read sed tutorials.

OTOH, the text in this particular case is not exactly "repeated" and not exactly the "same" as in the cfg file, so I might change my point of view regarding this particular line.

During the years, contributors come and go. When a change is needed and there is no knowledgeable developer around, "nothing" can be done. This type of comments (somehow repeating what is already "evident" and not really adding to the code) are not just unneeded but also unwanted by developers, but they help "common poor mortals" so to try to understand (the logic in the script) in case a change is needed in the future (or in customizations).

Ok, you persuaded me. Before you made this comment, I didn't know about the non-developers trying to customize the code. Now I'll make improvements that focus on readability for the "common poor mortals".

Regarding your other comments:@@ -12,11 +12,8 @@ : How about changing it to this?

Code:

# pwd-msys is a function that prints the working directory in the Windows # format. It is used in this script for displaying user messages.# You probably won't use it in other places. (Because Windows paths cannot be# interpreted in Unix shells.)# The '-w' switch in pwd works with MSYS Bash only.

@@ -161,9 +158,9 @@: By 'non-portable' I mean it's Bash-only. While it doesn't matter here I think using backticks are better.

@@ -176,7 +173,7 @@: You can keep using '-or' for easier understanding by the "mortal". I don't object that.

Ok, you persuaded me. Before you made this comment, I didn't know about the non-developers trying to customize the code. Now I'll make improvements that focus on readability for the "common poor mortals".

Not only customizations (which I usually try to keep in mind, but it is not the first concern). It already happened more than once that something was done for UBCD, and the original contributor is not around anymore. Until someone else with relevant skills shows up ("if" someone ever shows up), no changes to that "something" can be made. There is obviously a limit to how much something can be simplified or explained for "mortals" , but if it can be done then I would tend to favor that.

Quote:

Regarding your other comments:@@ -12,11 +12,8 @@ : How about changing it to this?

Code:

# pwd-msys is a function that prints the working directory in the Windows # format. It is used in this script for displaying user messages.# You probably won't use it in other places. (Because Windows paths cannot be# interpreted in Unix shells.)# The '-w' switch in pwd works with MSYS Bash only.

Sounds reasonable. Note that, at least in the way I used it in beta2, pwd-msys prints "Windows-like" paths under Windows, and Linux-like (not Windows-like) paths under Linux.

Quote:

@@ -161,9 +158,9 @@: By 'non-portable' I mean it's Bash-only. While it doesn't matter here I think using backticks are better.

Yes, I understood it as Bash-only. I (wrongly) thought that "echo -n" _was_ portable. I just re-checked it: Ubuntu's Dash includes it too, but it is not portable (no echo's options are). Using backticks _is_ better.

Quote:

@@ -176,7 +173,7 @@: You can keep using '-or' for easier understanding by the "mortal". I don't object that.

Understanding "-or" better than understanding "-o" is not a factor in this case, IMHO.

"Understanding" is nice; "correct functionality" is better. So the question is, which operators (POSIX ones or not) are better for this context where it has to work under Linux and Windows.

Potential scenario: several years from now someone suggests updating the auxiliary unxutils programs in UBCD because of some new need (or bug found, or whatever). Some MSYS tools are replaced by their CYGWIN counterparts, and the other way around (again, for some new needs, or customizations, or whichever other reason).

Giving this potential scenario, which operators (POSIX ones or not) would be more suited? I don't care if this script is usable "as-is" under, say, Solaris, or under any OS other than Linux and Windows.

So, I'm really asking. If "-o" is better suited for UBCD, let's use that. If "-or" is, then let's use it.

Sure, no problem. But I am still curious about your suggestion to change it to use "ORs" instead of multiple "NOTs" (specially since I originally intended to use "or" too). What made you think about changing it? And, have you tested it (since I originally had problems, thus I changed it to multiple "NOTs").

Understanding "-or" better than understanding "-o" is not a factor in this case, IMHO.

"Understanding" is nice; "correct functionality" is better. So the question is, which operators (POSIX ones or not) are better for this context where it has to work under Linux and Windows.

Potential scenario: several years from now someone suggests updating the auxiliary unxutils programs in UBCD because of some new need (or bug found, or whatever). Some MSYS tools are replaced by their CYGWIN counterparts, and the other way around (again, for some new needs, or customizations, or whichever other reason).

Giving this potential scenario, which operators (POSIX ones or not) would be more suited? I don't care if this script is usable "as-is" under, say, Solaris, or under any OS other than Linux and Windows.

So, I'm really asking. If "-o" is better suited for UBCD, let's use that. If "-or" is, then let's use it.

Ady sent me a PM about his "doubts" about these operators and want me to answer it.First, read this. You can see that in POSIX only the '-o' operator is defined.Next, let me quote a paragraph in the man page of GNU find:

Quote:

expr1 -o expr2 Or; expr2 is not evaluated if expr1 is true.

expr1 -or expr2 Same as expr1 -o expr2, but not POSIX compliant.

It clearly states that '-or' is not POSIX compliant, but GNU supports both operators. That's why if you are more concerned about portability, using '-o' is better.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum