nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

@INC reference issue - thoughts?

ChristianFracky

TS 6.5, Windows 2000 Server

Hi,

The following in b.ipl works fine:

use a;

but only if "a.pm" is located in the same directory as b.ipl or if a.pm is situated in one of the paths associated in @INC.

What is the syntax for moving "a.pm" elsewhere? For example, if I want to put "a.pm" in "e:\iw-home\custom\modules\aaaa", what is the syntax for the push statement in b.ipl? I've tried the following which does not work:

BEGIN {
push (@INC, '/iw-home/custom/modules/aaaa');
}
use a;

The following error is generated:

Can't locate a.pm in @INC (@INC contains: e:/iw-home/iw-perl/lib e:/iw-home/iw-p
erl/site/lib e:\iw-home\iw-perl\vendor\lib .) at E:\iw-home\custom\modules\b.ipl
line 4.
BEGIN failed--compilation aborted at E:\iw-home\custom\modules\b.ipl line 4.

Thanks in advance.

Find more posts tagged with

Comments

Migrateduser

You could do one of two things:

In your she-bang line, declare the following:

#!E:/iw-home/iw-perl/bin/iwperl -IE:/iw-home/custom/modules/aaaa

the "-I' flag includes the specified path to your @INC library. I tend not to prefer this method, however, but it's available.

The other thing you could do, which is far better, is to put whatever module you're trying to reference in E:/iw-home/iw-perl/site/lib -- create a directory at this level and put your module(s) into this subdirectory. This way, you won't need to do any of that stuff to the #! line and it's far cleaner. This is basically why the site directory is there anyway. Interwoven uses the vendor directory and site is basically ours to use.

ChristianFracky

That worked like a charm, thanks Dave.

Question: If the file is being developed in Windows, and later posted to a Unix server, can there be two she-bang lines? How can that be handled without editing the file before and after deployment?

Migrateduser

No you can't have two she-bang lines the second she-bang line will be ignored. You can use relative path in the she-bang line.

Adam Stoller

That worked like a charm, thanks Dave.

Question: If the file is being developed in Windows, and later posted to a Unix server, can there be two she-bang lines? How can that be handled without editing the file before and after deployment?

If you're not really intending the script to be used in Windows for the long term - put the correct Unix #! line in place.

Windows doesn't really use the #! line to find iwperl - though there are circumstances on Windows where the information in that line is used and/or can make a difference.

If you need to support both enviornments concurrently - you're best off having an installation process and having the 'source' use something like

#!__IWHOME__/iw-perl/bin/iwperl

and then have a script that "munges" the installed script to replace __IWHOME__ with the actual path (I believe you'll find such a script in the IWHOME/install directory - but it's pretty simple to write yourself.

Migrateduser

Is it really not possible to put your module under iw-perl/site/lib? It would make your migration less of a headache -- not that I'm not impressed with fish's pimped out technique of constructing the she-bang line... very cool! But this would seem to involve far less work for the same result.

Adam Stoller

Is it really not possible to put your module under iw-perl/site/lib? It would make your migration less of a headache -- not that I'm not impressed with fish's pimped out technique of constructing the she-bang line... very cool! But this would seem to involve far less work for the same result.

There are two issues being discussed here:

Personally, I haven't had to work in that kind of environment any time recently - the closest I've come is where I've developed code for one environment on one platform, and then re-used the code in another environment on another platform - and in those cases I just make sure to fix all the #! lines for the new environment.

Migrateduser

Fish, in your opinion, wouldn't he be in a better position to put this module in site/lib or are you in favor of parsing the she-bang line? The latter is very cool and everything but it just seems like far more work, if the former is an option.

Adam Stoller

Fish, in your opinion, wouldn't he be in a better position to put this module in site/lib or are you in favor of parsing the she-bang line? The latter is very cool and everything but it just seems like far more work, if the former is an option.

Yes - in my opinion - putting the modules into site/lib is the way to go - that was the first issue discussed in this thread.

The she-bang line issue has to do with the scripts utilizing the modules.

True - if the modules are already in the @INC path - by virtue of being placed in site/lib - then the issues surrounding the #! line in the script largely go away (you can use the unix path there, and it will still work on Windows because in most cases you have to explicitly call the script as an argument to iwperl instead of the OS implicitly finding it for you)

The one place where this does tend to become an issue is with CGI scripts - because in some cases (and I really do not remember exactly which ones) having the proper Windows #! line in your .ipl file will allow you to use the .ipl file as a CGI script without the need for creating a binary wrapper (copy of show_env.cgi to your_script.cgi). It's in this situation where you mostly need the notion of a 'munger' script to replace the #! line in the scripts (not the modules - they shouldn't have one) with the correct path to iwperl for that environment.

ChristianFracky

Is it really not possible to put your module under iw-perl/site/lib? It would make your migration less of a headache -- not that I'm not impressed with fish's pimped out technique of constructing the she-bang line... very cool! But this would seem to involve far less work for the same result.

Desire is to have all custom code in a single location when possible, hence the desire for a targeted location.

Thanks for all the great input, guys!

Migrateduser

Okay, well if it suits you (and if you can with your infrastructure), you could create a directory in iw-perl/site/lib called custom and put your a.pm in that directory.

Which way do you think you're going to go?

ChristianFracky

Okay, well if it suits you (and if you can with your infrastructure), you could create a directory in iw-perl/site/lib called custom and put your a.pm in that directory.

Which way do you think you're going to go?

I think I have the workaround. At the start of my file, I am going to do the following:

BEGIN {
push (@INC, '/iw-home/custom/modules');
push (@INC, 'e:/iw-home/custom/modules');
}

which is working fine on windows without the she-bang (my original post did not have the e:/ line, which, once added, the module started to work).

Not overly clean I suppose, but works like a charm in Windows. Will try out Unix in a couple of days.

Adam Stoller

I think I have the workaround. At the start of my file, I am going to do the following:

BEGIN {
push (@INC, '/iw-home/custom/modules');
push (@INC, 'e:/iw-home/custom/modules');
}

which is working fine on windows without the she-bang (my original post did not have the e:/ line, which, once added, the module started to work).

Not overly clean I suppose, but works like a charm in Windows. Will try out Unix in a couple of days.

If you don't care about clean engineering of your code - yes that will work just fine.
If you want something a bit better engineered:

...
use TeamSite::Config;
my $iwhome;
BEGIN{
   $iwhome = TeamSite::Config::iwgethome();
};
use lib "$iwhome/custom/modules";
...

As with most things Perl - there are many ways to do things - but what we've mostly been trying to talk about are "best practices" - which neither your solution nor my re-engineered version of your solution fall into (IMO).

However - if it works and you're happy with it - go have fun.