Jump to content

Porting WeiDU mods to Linux - initial thoughts


the bigg

Recommended Posts

I guess that uppercase 'Items' in the for loop should be lowercase.

Apart from that it should work, assuming the file has execution permissions. (The shell looks for the shebang to determine the interpreter.)

 

Probably would have done it like that:

#!/bin/sh
SOX=song_and_silence/audio/sox
for file in song_and_silence/items/a!ra0*.ogg ; do
$SOX $file override/$(basename $file .ogg).wav
done

But stick with your code, since I tend to produce buggy code when programming on weekend. :p

 

/Edit: Strange, that code tag is eating some spaces. (no-break space to the rescue)

Link to comment

Well CMorgan, I guess now isn't the best time to say that you need "shopt -s nocaseglob". I have a half-assed excuse available upon request. So:

 

#!/bin/bash

shopt -s nocaseglob

for file in `cd song_and_silence/Items; echo a!ra0*.ogg`; do

song_and_silence/audio/sox song_and_silence/Items/$file override/${file%.ogg}.wav

done

 

Similarly for uninstall,

#!/bin/bash

shopt -s nocaseglob

rm -f override/a!ra0*.wav

 

> I am assuming that the OS/WeiDU sees "shell file - run this with whatever is on the first line"

No, you're telling it what to use when you specify "sh" or "bash" in the AT_NOW command. The "#!/bin/bash" line doesn't do anything, it's just a comment.

 

By the way, why do you use AT_INTERACTIVE_UNINSTALL instead of AT_UNINSTALL?

 

> I guess that uppercase 'Items' in the for loop should be lowercase.

It doesn't matter for MacOSX.

 

The reason I don't use "basename" is I've heard that some early versions of MacOSX don't put /usr/bin in the default PATH.

 

I'm ready to take your recriminations, CM.

Link to comment
Well CMorgan, I guess now isn't the best time to say that you need "shopt -s nocaseglob".

Shouldn't the filenames be all lowercase for unix installs, anyhow?

 

> I am assuming that the OS/WeiDU sees "shell file - run this with whatever is on the first line"

No, you're telling it what to use when you specify "sh" or "bash" in the AT_NOW command. The "#!/bin/bash" line doesn't do anything, it's just a comment.

You are wrong here. If the file is executable, you don't need to specify the interpreter in the AT_NOW. (But you need to prefix the file with ./ if it's in the current working directory.)

 

> I guess that uppercase 'Items' in the for loop should be lowercase.

It doesn't matter for MacOSX.

What I really wanted to say was, that the both lines referring to the Items dir should match, since most unix filesystems are case sensitive.

Link to comment

> Shouldn't the filenames be all lowercase for unix installs, anyhow?

 

HFS is a case-insensitive file system, like Windows'. The "nocaseglob" option tells bash to also be case-insensitive, which only matters when it's expanding filenames with wildcards.

 

> If the file is executable, you don't need to specify the interpreter in the AT_NOW.

 

True, but CM is specifying the interpreter. It's the best way considering the number of archive programs that fail to set execute permission.

 

I'm pretty sure we've confused CM to the point of ignoring us. Maybe to the point of hiring a hitman to "solve" this problem.

Link to comment
HFS is a case-insensitive file system, like Windows'. The "nocaseglob" option tells bash to also be case-insensitive, which only matters when it's expanding filenames with wildcards.

I somehow assumed that he uses the same scripts for MacOS and Linux.

It looks like this isn't the case here.

 

True, but CM is specifying the interpreter. It's the best way considering the number of archive programs that fail to set execute permission.

Agreed.

 

I'm pretty sure we've confused CM to the point of ignoring us. Maybe to the point of hiring a hitman to "solve" this problem.

Yeah, I'm sorry 'bout that. Should have probably kept my mouth shut.

Link to comment

Hells, no, dudes - this is how I learn :p I promise I will come back with questions. It took several years to standardize installers (and they still aren't standardized even on just G3) so we can either update the current installers or take the feedback and set it up for the next version - and anything as yet unreleased can be updated before it rolls out.

 

It is a moving target, after all, and a hobby.

 

So far, I am lowercasing everything and not putting out the .exe because that is both the smallest download and the simplest way for self-customization. .tp2 stuff is non-case-sensitive, but the shell scripts are, so I am making sure everything on *all* platfoms is lowercased, so eventually all a person has to do to "follow the format" and get their mod to run on all three is to write everything lowercase and be done with it, swapping out the ,.exe or deleting it.

 

I can include the shopt -s nocaseglob even if it isn't strictly necessary, just in case someone makes a mistake on case sensitivity or doesn't run "tolower".

 

Is there a functional reason why AT_UNINSTALL instead of AT_INTERACTIVE_UNINSTALL? I have assumed the best practice was to keep the sound stuff running in the middle of a mod so no one gets fancy on closing the command process before it finishes, but since we are specifying OS if there is a better/easier way on Linux, let's do it.

 

The end result is supposed to be a pretty much modder/player proof distribution that means folks can use or create any one of the installers even if they are completely new to the OS.

Link to comment

That means we lop off anyone using weidu --uninstall stuff, etc, right... plus anyone who builds an automated routine. OK. Probably not a great way of coding that.

 

If we are correct in this, then we had better change best recommended practices to get rid of the _INTERACTIVE.

Link to comment

*_INTERACTIVE is run on --uninstall et al.

 

The definition of interactive or not is as follows:

- if the component is (un)installed because WeiDU is traversing the weidu.log stack, it is non interactive.

- Otherwise, it's interactive.

Link to comment

Question for the Linux Folks:

 

on Windows, we have

 

@echo off

attrib -r override\loadcntr.bam
attrib -r override\gprogbar.mos
attrib -r override\gtrspsk.mos
attrib -r override\gtrspsk2.mos
attrib -r override\stoneopt.mos

del override\loadcntr.bam
del override\gprogbar.mos
del override\gtrspsk.mos
del override\gtrspsk2.mos
del override\stoneopt.mos

 

 

On OS X, we have

#!/bin/sh

del_files="loadcntr.bam gprogbar.mos gtrspsk.mos gtrspsk2.mos stoneopt.mos"

for file in $del_files; do
 rm override/$file
done

 

For Linux, we have

nothing.

 

If we want to convert this so it is uniform, specific, and works on Linux, could you folks please check this code?

 

<back in a second>

 

windows:

@echo off

attrib -r override\loadcntr.bam
attrib -r override\gprogbar.mos
attrib -r override\gtrspsk.mos
attrib -r override\gtrspsk2.mos
attrib -r override\stoneopt.mos

del override\loadcntr.bam
del override\gprogbar.mos
del override\gtrspsk.mos
del override\gtrspsk2.mos
del override\stoneopt.mos

OS X:

#!/bin/sh
rm override/loadcntr.bam 
rm override/gprogbar.mos 
rm override/gtrspsk.mos 
rm override/gtrspsk2.mos 
rm override/stoneopt.mos

Linux:

#!/bin/bash
shopt -s nocaseglob
rm -f override/loadcntr.bam 
rm -f override/gprogbar.mos 
rm -f override/gtrspsk.mos 
rm -f override/gtrspsk2.mos 
rm -f override/stoneopt.mos
Link to comment

Ok, can I run

 

if osx, then

sh

#!/bin/bash/sh
shopt -s nocaseglob
rm -f override/loadcntr.bam
rm -f override/gprogbar.mos
rm -f override/gtrspsk.mos
rm -f override/gtrspsk2.mos
rm -f override/stoneopt.mos

 

if not-x38 and not-osx then

bash

#!/bin/bash/sh
shopt -s nocaseglob
rm -f override/loadcntr.bam
rm -f override/gprogbar.mos
rm -f override/gtrspsk.mos
rm -f override/gtrspsk2.mos
rm -f override/stoneopt.mos

 

?

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...