Now i know that this is not a small package to request and that most users wont directly use it.

 

However Perl would give the community far more scripting power and all users would end up benefiting from that.

 

Would Perl be viable or too large?

I did a test, it takes up about 34MB of space.

You can install it yourself by downloading the package from http://packages.slackware.it/package.php?q=current/perl-5.8.8-i486-6

Then in an installpkg

 

add the lines into your go script on the boot drive and it will install every time you reboot.

Understood. Thing is I think it would be adventitious to have Perl in the common build. Then users can utilise scripts the community pulls together without modifiying the underlying OS install.

 

Shell scripting is great but Perl is was more powerful.

Although I agree, perl scripting is better then shell scripting.

I think the goal of unRAID was to be as lean as possible.

 

I'm sure after perl is installed, we'll have people wanting python...

then apache, mysql, and php, pretty soon it will be a full LAMP environment...

 

This is a major reason I installed the GIGABYTE RAMDRIVE.

I've been thinking of installing these packages on to a root (remap) area within that ram drive.

Then writing some script to link anything within the alternate root (remap) area to the root in ram.

 

Syntax like the following will install a package elsewhere.

ROOT=/mnt/disk1/unraid_altroot installpkg perl----.tgz (etc, etc)

 

Could be a way of adding external packages statically without adding to ram overhead.

 

Once the cache drive has RAID1 capability I think this would be the drive to use such as

/mnt/cache/.unraid_altroot ,etc, etc. (or where ever the recommended location is).

Couldn't agree more on the size thing hence the initial post questioning its size.

 

Lean is good, in fact we all know its one of unRAIDs best features but a single proper scripting language addition would be excellent. I choose to suggest Perl since i know it but it doesnt have to be. If consensus said Python then lets make it python or anything else for that matter.... just one and one only.

 

I dont suggest the addition of packages lightly but I think there is a strong case for this one that opens up a whole new realm of community hacks.

 

In essence all unRAId components are a trade of bloat vs. usefulness vs. features. Perl is one addition that allows endless other hacks at no extra cost.

I have no issue with keeping perl as an installable package, those who need it will be able to figure out where to install it based on their storage config.

 

unRAID already has three scriptable languages...

It has the unix shell, one of the most flexible.  Yes, it does not do networking itself, but with netcat, it is easy.

it has "awk" a very powerful scripting language.

it has "sed" (yeah, even it is scriptable)

 

Now, I do not disagree, perl or python would make some tasks easier, or some programs already written in them easier to port, but I think they should be optional packages, for those who need them.

 

I say this because my old MD1200 based unRAID server has been running fine with 512 meg of ram for over 2 years, and I have no real need to use part of its ram up to install perl to an in memory file system.  I have no real need to increase the ram either... so my vote is to let those who need the additional packages install them and to keep unRAID as lean as it can be (supporting current hardware with drivers as needed).

 

I'd rather see Tom focus his time on UPS support, and NFS support, and NTFS-3G support, and alternate file system support.. items that are high on the laundry list.

 

Joe L.

I think we (as the we know linux crowd) could do the UPS part.

 

The other two pieces must be up to Tom.

So I think we are in general agreement that Perl would be useful.

 

There is some debate on its inclusion as standard or as a user addition.

 

Its addition should be a low priority (although adding Perl is likely a simple job compared with some other things on the to do list)

 

Perhaps the easiest way to start this off is a user hack like we always do. Document it, and offer hackers the opportunity to offer up cool unRAID scripts.