I still frequently use require to load optional modules on-demand at run-time. There are other modules which can do the same but they are mostly wrappers around require. I don't see this usage pattern going away any time soon.

I can think of a lot of examples of where a module should be required, at runtime, rather than used at compiletime. Factory method patterns, providing implementation of functionality into code based on some logic, only needing to load a module if a specific condition is met, dependency injection, and so on. And there are times that filenames versus bareword module names are useful. If you search CPAN for the word 'require' you'll find a ton of use cases you probably haven't considered, and while many of them don't HAVE to be coded the way they were, many of them used require because it was the appropriate tool for the job.

It is not obsolete, require is used. One use case:

Usually there's a line reading

1;
[download]

As LanX pointed out, use is sort of a wrapper around require, but it doesn't return anything, it throws away the value returned by require. It is even a syntax error trying to assign from it:

$result = use Some::Module; # illegal
[download]

So you cannot assign from use, but you can from require. This is useful to load e.g. a config stash or getting back a data structure captured from Data::Dumper or Data::Dump into a file:

# file hash.pl
# anonymous hash reference
{
  name => 'foo',
  data => [1,2,3],
}
__END__
[download]

#!/usr/bin/perl
# file program.pl

use strict; use warnings;
use Data::Dump;
my $var = require './hash.pl';
dd $var;
__END__
[download]

Output:

{ data => [1, 2, 3], name => "foo" }
[download]

Of course, you can do arbitrary computations in the required file.

If you just want the last computed value from a file without having to declare an our variable in both source and target, or using Exporter, this is the way to do it - if you expect a true value to be returned. Otherwise, you would do FILE.

> require demands a true value from an included file.

Note that it might soon no longer demand it.

map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]

Except it's a really unreliable way to return a value.

require './hash.pl';

use strict; use warnings;
use Data::Dump;
my $var = require './hash.pl';
dd $var;
[download]

Hire me at Toby Ink Ltd or Join my OnlyFans

Except it's a really unreliable way to return a value.

This is an assertion without argument.

If it would be unreliable, it should fail sometimes - but it doesn't, only in the ways require does.

Yes, the example code is just bare-bone without any checks. It is also nonsensical because it doesn't do anything useful.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

• BEGIN { require Module; Module->import( LIST ); }

But there are many patterns where you explicitly don't want BEGIN or import or both to happen too.

Similar for do and eval

So, most of our Perl scripts that touch Sybase ASE start with something like:

# We need the $SYBASE and $LD_LIBRARY_PATH environment variables to be
+ able
# to use the Sybase::Simple library (because it links to libsybct.so i
+n
# $SYBASE/$SYBASE_OCS/lib), but if we are invoked through cron, then
# ~/.profile doesn't get sourced and we are stuck with a nearly empty 
+%ENV
# hash.  So if we detect $SYBASE is not in %ENV, reexec through a shel
+l that
# first sources in the necessary environment variables.

unless (exists $ENV{SYBASE}) {
    # $^X is the path to the current perl interpreter
    # $0 is the script itself
    exec '/bin/sh', '-c', ". /db/sybsdk/SYBASE.sh ; exec $^X $0 @ARGV"
+;
}

# even with the above, we need to wrap the import of the Sybase Perl
# module in a runtime block as to avoid initialization by the Perl com
+piler
# prior to runtime (which checks for the necessary $SYBASE env variabl
+es).
# See 'perldoc perlfaq8' as to the difference between 'use' and 'requi
+re'.
# Basically: 'use' is ran at compile time, 'require' at runtime.
require Sybase::Simple;
[download]

Are you interested in other solutions?
• either: avoid require by putting the exec part in a BEGIN block to execute it at compile time prior to use
• or: avoid exec-restart-voodoo by importing the necessary ENV directly from a shell file. (see last update in Re^3: How to "source" a shell file in Perl? (Trojan Dump))
• combine both

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

Thanks for the input and the clever alternative of forking a subshell, dotsourcing any shellscripts in said subshell that modify the environment, and then serializing over the %ENV hash and eval'ing it in the parent process. This works for most normal environment variables, but not the ones that these Sybase libraries need. In particular, the Sybase libraries need custom LD_LIBRARY_PATH environment settings. LD_LIBRARY_PATH is interpreted by the OS's ld.so dynamic linker, but only at process initialization. Setting LD_LIBRARY_PATH from within a process will not affect the library search path of the process itself, only for subsequent childs the process launches. To expound on the problem, see the following transcript (env -i clears the environment):

$ env -i PERL5LIB=.local/lib/perl5 perl -MSybase::Simple
Can't load '.local/lib/perl5/x86_64-linux-thread-multi/auto/Sybase/CTl
+ib/CTlib.so' for module Sybase::CTlib: libsybct_r64.so: cannot open s
+hared object file: No such file or directory at /usr/lib64/perl5/Dyna
+Loader.pm line 193.
 at .local/lib/perl5/Sybase/Simple.pm line 19.
Compilation failed in require at .local/lib/perl5/Sybase/Simple.pm lin
+e 19.
BEGIN failed--compilation aborted at .local/lib/perl5/Sybase/Simple.pm
+ line 19.
Compilation failed in require.
BEGIN failed--compilation aborted.
$
[download]

The PERL5LIB environment variable is the only one that is set in the empty environment that launches the perl binary (to find the Sybase::Simple module). And indeed, in an empty environment, the XS .so blob that implements the actual database access layer in Sybase::CTlib (on which Sybase::Simple depends) refers to libraries that can't be resolved (and this is how these Sybase libraries work by design):

$ env -i ldd .local/lib/perl5/x86_64-linux-thread-multi/auto/Sybase/CT
+lib/CTlib.so
        linux-vdso.so.1 (0x00007ffcebdce000)
        libsybct_r64.so => not found
        libsybcs_r64.so => not found
        libsybblk_r64.so => not found
        libperl.so.5.32 => /lib64/libperl.so.5.32 (0x00007f4970c00000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4970800000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4970b25000)
        libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f4970fc3000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4971032000)
$
[download]

The code I arrived at from your linked comment to 'steal' the environment from a subshell (with the added requirement of merging with any existing %ENV values), is:

#!/usr/bin/perl

BEGIN {
  my $shellcode = <<__KOEKOEK__;
. sybsdk/SYBASE.sh
perl -MData::Dumper -e 'print Dumper [\%ENV]'
__KOEKOEK__

  %ENV = (%ENV => @{eval qx{/bin/sh -c "$shellcode"}});
};

print $ENV{LD_LIBRARY_PATH};

require Sybase::Simple;
[download]

But this still fails (even though the environment is modified correctly (the first line is the content of $ENV{LD_LIBRARY_PATH}):

$ env -i PERL5LIB=.local/lib/perl5 perl ./do_shell_source.pl
~/sybsdk/DataAccess64/ODBC/lib:~/sybsdk/DataAccess/ODBC/lib:~/sybsdk/O
+CS-20_0/lib:~/sybsdk/OCS-20_0/lib3p64:~/sybsdk/OCS-20_0/lib3p:
Can't load '.local/lib/perl5/x86_64-linux-thread-multi/auto/Sybase/CTl
+ib/CTlib.so' for module Sybase::CTlib: libsybct_r64.so: cannot open s
+hared object file: No such file or directory at /usr/lib64/perl5/Dyna
+Loader.pm line 193.
 at .local/lib/perl5/Sybase/Simple.pm line 19.
Compilation failed in require at .local/lib/perl5/Sybase/Simple.pm lin
+e 19.
BEGIN failed--compilation aborted at .local/lib/perl5/Sybase/Simple.pm
+ line 19.
Compilation failed in require at ./do_shell_source.pl line 14.
$
[download]

If we modify the script to just dump the %ENV hash, we see that all environment variables were indeed set correctly in the parent process from our detour in the qx{} subshell:

#!/usr/bin/perl

BEGIN {
  my $shellcode = <<__KOEKOEK__;
. sybsdk/SYBASE.sh
perl -MData::Dumper -e 'print Dumper [\%ENV]'
__KOEKOEK__

  %ENV = (%ENV => @{eval qx{/bin/sh -c "$shellcode"}});
};
use DDP;
p %ENV;
[download]

$ env -i PERL5LIB=.local/lib/perl5 perl ./do_shell_source.pl
{
    _                 "/usr/bin/perl",
    INCLUDE           "~/sybsdk/OCS-20_0/include:",
    LD_LIBRARY_PATH   "~/sybsdk/DataAccess64/ODBC/lib:~/sybsdk/DataAcc
+ess/ODBC/lib:~/sybsdk/OCS-20_0/lib:~/sybsdk/OCS-20_0/lib3p64:~/sybsdk
+/OCS-20_0/lib3p:",
    LIB               "~/sybsdk/OCS-20_0/lib:",
    PATH              "~/sybsdk/tools/bin:~/sybsdk/OCS-20_0/bin:/usr/l
+ocal/bin:/usr/bin",
    PERL5LIB          ".local/lib/perl5",
    PWD               "/tmp",
    SAP_JRE8          "~/sybsdk/shared/SAPJRE-8_1_062_64BIT",
    SAP_JRE8_64       "~/sybsdk/shared/SAPJRE-8_1_062_64BIT",
    SHLVL             0,
    SYBASE            "~/sybsdk",
    SYBASE_OCS        "OCS-20_0",
    SYBROOT           "~/sybsdk"
}
$
[download]

And this corresponds to what's inside the (Sybase provided) shell script file for their proprietary libraries that is meant to be sourced in the shell's environment:

$ cat sybsdk/SYBASE.sh
#
# SAP Product Environment variables
#
SAP_JRE8="~/sybsdk/shared/SAPJRE-8_1_062_64BIT"
export SAP_JRE8
SAP_JRE8_64="~/sybsdk/shared/SAPJRE-8_1_062_64BIT"
export SAP_JRE8_64
SYBASE_OCS="OCS-20_0"
export SYBASE_OCS
INCLUDE="~/sybsdk/OCS-20_0/include":$INCLUDE
export INCLUDE
LIB="~/sybsdk/OCS-20_0/lib":$LIB
export LIB
PATH="~/sybsdk/OCS-20_0/bin":$PATH
export PATH
#
# Replace lib, lib3p, and lib3p64 with devlib, devlib3p, and devlib3p6
+4 when debugging
#
LD_LIBRARY_PATH="~/sybsdk/OCS-20_0/lib:~/sybsdk/OCS-20_0/lib3p64:~/syb
+sdk/OCS-20_0/lib3p":$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
SYBASE="~/sybsdk"
export SYBASE
LD_LIBRARY_PATH="~/sybsdk/DataAccess/ODBC/lib":$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
LD_LIBRARY_PATH="~/sybsdk/DataAccess64/ODBC/lib":$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
SYBROOT="~/sybsdk"
export SYBROOT
PATH="~/sybsdk/tools/bin":$PATH
export PATH
$
[download]

So, coming back around again: a re-exec is still required in this case (due to the semantics and interaction of LD_LIBRARY_PATH and the system's dynamic linker). Moreover, because a Perl script file is first compiled before it is executed, any statements that fire at compile time (like use) need to be deferred to runtime (using require) when LD_LIBRARY_PATH potentially needs adjustments. Otherwise, the use Sybase::Simple; statements gets triggered before the re-exec through a shell that first sets LD_LIBRARY_PATH, causing compilation to abort due to DynaLoader getting an error from the OS's ld.so when trying to resolve libraries a module's XS .so file is linked to.