hi Gawk Team!

some months ago i was sending here some of the @include directive
helpfull features - and i want to pay your attention again about one
small feature that i was suggesting:

all files that was @included as the part of the gawk's script source, including main file are present in the predefined global array PROCINFO[ "include" ] for
each file included:

@include "abc.gwk"
# PROCINFO[ "include" ][ "abc" ] = "filepath/" abc.gwk

this feature is able to know at the user level the exact filepath of
itself code.
at this moment i may provide at least two examples because of why this
feature is really needfull:

1) as i said previously: an library may needs some files during i's
initialization. and this file should be placed near with the file
@included. and there is no possibility to read that kind of files
because we don't know WHERE required file is located.
as example of such kind files i was reporting exact mylife-cases:
- library for generating graphic files was needs the default.bmp and
default palette files
- an text-macro service library was requring to load auto macro definition file

2) now there is another case why this feature will be really helpful:
- one of my gawk library have self-modification feature: it's reading
ITSELF FILE and compares it with the stored copy of itself file that
is placed NEAR ITSELF FILE. if files are not equal to each other then
copy of the file is refreshed and self-modification process performed
generating new version of itself file.

after rewriting library-itself file by generated new itself-version
gawk's execution will be aborted because of requiring gawk script
restart.
the self-modification feature is allows to quckly operates with the
library's constant values.

in fact without this feature an multiple hardcoded filepaths are
using. this leads to fact that gawk script by default never can be
portable or have multiplatform support (the cases that i having in my
job)
the suggested feature is small, safe and strong.
may its have a chance just to be discussed by the Gawk Team? =)

note: possibly Dynamic Extensions may also needs in such like feature

with Respect
Denis

On 3/17/2022 2:43 PM, Digi wrote:
> hi Gawk Team!
>
> some months ago i was sending here some of the @include directive
> helpfull features - and i want to pay your attention again about one
> small feature that i was suggesting:
>
> all files that was @included as the part of the gawk's script source, including main file are present in the predefined global array PROCINFO[ "include" ] for
> each file included:
>
> @include "abc.gwk"
> # PROCINFO[ "include" ][ "abc" ] = "filepath/" abc.gwk
>
> this feature is able to know at the user level the exact filepath of
> itself code.
> at this moment i may provide at least two examples because of why this
> feature is really needfull:
>
> 1) as i said previously: an library may needs some files during i's
> initialization. and this file should be placed near with the file
> @included. and there is no possibility to read that kind of files
> because we don't know WHERE required file is located.
> as example of such kind files i was reporting exact mylife-cases:
> - library for generating graphic files was needs the default.bmp and
> default palette files
> - an text-macro service library was requring to load auto macro definition file
>
> 2) now there is another case why this feature will be really helpful:
> - one of my gawk library have self-modification feature: it's reading
> ITSELF FILE and compares it with the stored copy of itself file that
> is placed NEAR ITSELF FILE. if files are not equal to each other then
> copy of the file is refreshed and self-modification process performed
> generating new version of itself file.
>
> after rewriting library-itself file by generated new itself-version
> gawk's execution will be aborted because of requiring gawk script
> restart.
> the self-modification feature is allows to quckly operates with the
> library's constant values.
>
> in fact without this feature an multiple hardcoded filepaths are
> using. this leads to fact that gawk script by default never can be
> portable or have multiplatform support (the cases that i having in my
> job)
> the suggested feature is small, safe and strong.
> may its have a chance just to be discussed by the Gawk Team? =)
>
> note: possibly Dynamic Extensions may also needs in such like feature
>
> with Respect
> Denis

Usenet isn't how to contact the gawk team, see
https://www.gnu.org/software/gawk/manual/gawk.html#Asking-for-help.

Ed.

On 17.03.2022 20:43, Digi wrote:
> hi Gawk Team!

Note that this newsgroup and its audience is not the "Gawk Team".

> some months ago i was sending here some of the @include directive
> helpfull features - and i want to pay your attention again about one
> small feature that i was suggesting:
> [...]

At that time you haven't got any feedback but the one Ed already gave
you. And I agree with Ed about the better place for feature requests.
Although this newsgroup is certainly a good place to discuss a feature
before submitting it to the design/development team, your suggestion
appears to me to be a bit muddled and not very well motivated; that
may also be the reason why yet no one cared to respond.

Janis

me gawk expirience is more than ten years.

the offer is extremely simple and specific. external files may be needed for various parts of the code to work. where do I load them from? how do I find out where gawk eventually found this or that library to read a file located nearby? if you haven't such like cases in practice, then you simply did not write code on gawk more complicated than just ABC. as a result, I have to use hardcoded filepaths. and this means that my gawk code is not able to work, not only on different platforms, it will not be able to work on two machines with the same OS without first preparing the infrastructure - copying and locating libraries locally, as well as specifying new paths. and only then - the launch.this is an extremely simple sentence and I have indicated the motivation. if you have some library that "wants" a certain file for its work, then you cannot make it full-fledged - because you do not know the path from where to read the necessary files. what do you find incomprehensible(muddled) or confusing(unmotivated) here?

PROCINFO[ "include" ][ filename(no ext) ] == full filepath to file included

In article <b0b6ebd7-bac8-4d98-aab3-4fa05ecc5f84n@googlegroups.com>,
Digi <cosmogen@gmail.com> wrote:
>me gawk expirience is more than ten years.
>
>the offer is extremely simple and specific, etc

I think it boils down to this:

1) There are very few people who read this newsgroup and are able to
implement what you want to see implemented. Depending on how you count
it, that number is probably at most 3.

So, people are going to either ignore you, insult you, or suggest workarounds.

2) It doesn't sound to me like the sort of thing that the implementors are
likely to be interested in. But I could be wrong about that; I have been
wrong in the past.

3) It sounds like there is something wrong with your software environment.
Whatever it is that you're trying to do, it shouldn't be this hard. I
would tend to assume that that's the core problem, and that's the thing
that needs to be fixed.

Now, that's not to say that you can't get yourself into a snarl with this
stuff, because I have done so on at least one of my machines. This happens
because of the different versions of the extension library API. However, I
don't think that you should be having this problem in the context of
"include" files, since they are just AWK code and thus generic. I got
myself into a mess on one of my machines by having multiple versions of
GAWK which requires maintaining multiple versions of my extension
libraries. (Yes, I know this shouldn't happen, but, as they say, S
happens...)

4) As my suggested workaround, why not try running your GAWK program with
"strace" - with whatever option says to track the "open" system call - and
with the strace output going to a file. Then your AWK script can parse
that file in real time and find all the files that have been opened so far.
That ought to get you started on the road (to wherever it is you're trying
to get to...)

--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."

- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

I guess AWKPATH is the answer to all your questions.

HTH.

El 18/03/2022 a las 20:29, Digi escribió:
> me gawk expirience is more than ten years.
>
> the offer is extremely simple and specific. external files may be
needed for various parts of the code to work. where do I load them from?
how do I find out where gawk eventually found this or that library to
read a file located nearby? if you haven't such like cases in practice,
then you simply did not write code on gawk more complicated than just
ABC. as a result, I have to use hardcoded filepaths. and this means that
my gawk code is not able to work, not only on different platforms, it
will not be able to work on two machines with the same OS without first
preparing the infrastructure - copying and locating libraries locally,
as well as specifying new paths. and only then - the launch.this is an
extremely simple sentence and I have indicated the motivation. if you
have some library that "wants" a certain file for its work, then you
cannot make it full-fledged - because you do not know the path from
where to read the necessary files. what do you find
incomprehensible(muddled) or confusing(unmotivated) here?
>
> PROCINFO[ "include" ][ filename(no ext) ] == full filepath to file included
>

--
Manuel Collado - http://mcollado.z15.es

In article <6235A9EC.6060003@users.sourceforge.net>,
Manuel Collado <m-collado@users.sourceforge.net> wrote:
>I guess AWKPATH is the answer to all your questions.

No, it isn't. Certainly not the answer to the question as posed (which is
"I want to know from whence any/all of my include files came").

Although, as I hint in my previous response, a sensible setting of AWKPATH
and some cleanup/re-organization of OP's software envrionment (aka,
ecosystem) may, in fact, be part of the long term solution to OP's issues.

But, the fact is, we still really don't know (and probably never will) what
OP's real, underlying problem is.

--
It's all Al Gore's fault...

On 2022-03-19, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <6235A9EC.6060003@users.sourceforge.net>,
> Manuel Collado <m-collado@users.sourceforge.net> wrote:
>>I guess AWKPATH is the answer to all your questions.
>
> No, it isn't. Certainly not the answer to the question as posed (which is
> "I want to know from whence any/all of my include files came").
>
> Although, as I hint in my previous response, a sensible setting of AWKPATH
> and some cleanup/re-organization of OP's software envrionment (aka,
> ecosystem) may, in fact, be part of the long term solution to OP's issues.
>
> But, the fact is, we still really don't know (and probably never will) what
> OP's real, underlying problem is.

The motivation here seems to be not knowing where materials are coming
from, and possibly some issues related to that: something coming from
the wrong place leading to wrong results.

If you have some @include "foo.bar" or whatever, the obvious answer
about where it is coming from is that you have a "foo.bar" file
somewhere in the tree, and it's the only file with that name.

You'd only have to ask where that include is coming from if it is
ambiguous. It would only be ambiguous if there are multiple files by the
same name that could possibly be included, and you don't understand or
control the resolution process.

The fix would be to stop the ambiguity (rename your files, or use
directory prefixes like @include "parser/foo.bar") and/or gain
understanding and control over the process; and neither of those
requires a way to list the includes.

I've been in the situation a few times over the years where in some
C preprocessing mess it was unclear where a header was coming from.
E.g. a build machine's own headers being pulled into a cross-compile,
and such. In those cases you can capture the preprocessed output,
and that has the trace lines ("linemarkers" according to GNU
documentation) which tell you which files were pulled in.

Without such a trace, I concur with your earlier answer that I would
whip out strace.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

On 19/03/2022 11:39, Kenny McCormack wrote:
> In article<6235A9EC.6060003@users.sourceforge.net>,
> Manuel Collado<m-collado@users.sourceforge.net> wrote:
>> I guess AWKPATH is the answer to all your questions.
> No, it isn't. Certainly not the answer to the question as posed (which is
> "I want to know from whence any/all of my include files came"
As I understand it, @include only takes strings (not variables) so the
'basename' of the file to be included is always known. And AWKPATH is
the only environment variable (plus the current directory) which tells
the @include mechanism where to look.

Since the value of AWKPATH is available to the running AWK program, it
would seem to be simple enough to write a function that takes the
include file name and does an equivalent search through AWKPATH,
stopping at the first match which will be the file that was included.

Nested @includes (are they allowed?) could do the same thing themselves
so that a results array equivalent to PROCINFO[ "include" ][ filename(no
ext) ] is built-up.

Am I missing something here?

--
Bruce Horrocks
Surrey, England

In article <e092806e-f04b-d5bc-f9ed-06bb3bb84636@scorecrow.com>,
Bruce Horrocks <07.013@scorecrow.com> wrote:
>On 19/03/2022 11:39, Kenny McCormack wrote:
>> In article<6235A9EC.6060003@users.sourceforge.net>,
>> Manuel Collado<m-collado@users.sourceforge.net> wrote:
>>> I guess AWKPATH is the answer to all your questions.
>> No, it isn't. Certainly not the answer to the question as posed (which is
>> "I want to know from whence any/all of my include files came"

>As I understand it, @include only takes strings (not variables) so the
>'basename' of the file to be included is always known.

Yes, this is true.

But it underscores the real problem here, which is we really have no idea
what OP's actual problem is. And we probably never will, due to the
language barrier, that prevents him from explaining it.

If anyone here not so encumbered (by a language barrier) could explain to
me what they think OP's actually problem is, I'd be most grateful.

>And AWKPATH is
>the only environment variable (plus the current directory) which tells
>the @include mechanism where to look.

What I am about to say has nothing to do with the thread topic, but is just
an FYI, regarding your parenthetical above. The default AWKPATH has "."
(dot) as its first element, and bad things can happen if "." is not in
AWKPATH. I.e., GAWK's AWKPATH follows the Unix model - where "." must be
explicitly included in order for the current directory to be searched - and
not the Windows model (where . is always searched).

>Since the value of AWKPATH is available to the running AWK program, it
>would seem to be simple enough to write a function that takes the
>include file name and does an equivalent search through AWKPATH,
>stopping at the first match which will be the file that was included.

Again, this depends on what OP's actual problem is.

Metaphorically, you can think of this as the difference between:

1) I've gotten myself into a deep, dark hole. I need help clawing my
way out of it.
vs.
2) I'm trying to build a system to keep myself safe from falling into a hole.

My sense is that OP is in case 1 above, but we're all acting like it is
case 2.

>Nested @includes (are they allowed?)

Yes, of course.

>could do the same thing themselves
>so that a results array equivalent to PROCINFO[ "include" ][ filename(no
>ext) ] is built-up.
>
>Am I missing something here?

Wihtout clarification from OP, we'll never know.

--
The difference between communism and capitalism?
In capitalism, man exploits man. In communism, it's the other way around.

- Daniel Bell, The End of Ideology (1960) -

El 20/03/2022 a las 0:09, Bruce Horrocks escribió:
> On 19/03/2022 11:39, Kenny McCormack wrote:
>> In article<6235A9EC.6060003@users.sourceforge.net>,
>> Manuel Collado<m-collado@users.sourceforge.net> wrote:
>>> I guess AWKPATH is the answer to all your questions.
>> No, it isn't. Certainly not the answer to the question as posed
>> (which is
>> "I want to know from whence any/all of my include files came"
> As I understand it, @include only takes strings (not variables) so the
> 'basename' of the file to be included is always known. And AWKPATH is
> the only environment variable (plus the current directory) which tells
> the @include mechanism where to look.
>
> Since the value of AWKPATH is available to the running AWK program, it
> would seem to be simple enough to write a function that takes the
> include file name and does an equivalent search through AWKPATH,
> stopping at the first match which will be the file that was included.

Yes. What about the next code?

# Check if a file exists
function file_exists(file, rc, line) {
rc = getline line < file
if (rc >= 0) {
close(file)
return 1
} else {
return 0
}
}

# Return the effective path of an @include file
function which(script, awkpath, k) {
split(ENVIRON["AWKPATH"], awkpath, ":")
for (k=1; k in awkpath; k++) {
if (file_exists(awkpath[k] "/" script)) {
return awkpath[k] "/" script
} else if (file_exists(awkpath[k] "/" script ".awk")) {
return awkpath[k] "/" script ".awk"
}
}
}

The OP could test it and tell us if it solves the problem.

--
Manuel Collado - http://mcollado.z15.es

This is similar to the code in the igawk.sh script which comes
with the gawk distribution. That program could easily be modified
to set up an array with the information that the OP desired.

As such, it is rather unlikely that his requested feature would
be added to gawk itself.

In article <t181fm$bb2$1@gioia.aioe.org>,
Manuel Collado <m-collado@users.sourceforge.net> wrote:
>El 20/03/2022 a las 0:09, Bruce Horrocks escribió:
>> On 19/03/2022 11:39, Kenny McCormack wrote:
>>> In article<6235A9EC.6060003@users.sourceforge.net>,
>>> Manuel Collado<m-collado@users.sourceforge.net> wrote:
>>>> I guess AWKPATH is the answer to all your questions.
>>> No, it isn't. Certainly not the answer to the question as posed
>>> (which is
>>> "I want to know from whence any/all of my include files came"
>> As I understand it, @include only takes strings (not variables) so the
>> 'basename' of the file to be included is always known. And AWKPATH is
>> the only environment variable (plus the current directory) which tells
>> the @include mechanism where to look.
>>
>> Since the value of AWKPATH is available to the running AWK program, it
>> would seem to be simple enough to write a function that takes the
>> include file name and does an equivalent search through AWKPATH,
>> stopping at the first match which will be the file that was included.
>
>Yes. What about the next code?
>
># Check if a file exists
>function file_exists(file, rc, line) {
> rc = getline line < file
> if (rc >= 0) {
> close(file)
> return 1
> } else {
> return 0
> }
>}
>
># Return the effective path of an @include file
>function which(script, awkpath, k) {
> split(ENVIRON["AWKPATH"], awkpath, ":")
> for (k=1; k in awkpath; k++) {
> if (file_exists(awkpath[k] "/" script)) {
> return awkpath[k] "/" script
> } else if (file_exists(awkpath[k] "/" script ".awk")) {
> return awkpath[k] "/" script ".awk"
> }
> }
>}
>
>The OP could test it and tell us if it solves the problem.
>
>--
>Manuel Collado - http://mcollado.z15.es

On 2022-03-21, Mack The Knife <mack@the-knife.org> wrote:
> This is similar to the code in the igawk.sh script which comes
> with the gawk distribution. That program could easily be modified
> to set up an array with the information that the OP desired.
>
> As such, it is rather unlikely that his requested feature would
> be added to gawk itself.

The new Awk with C Preprocessor (cppawk) solves the problem
like this:

What is the value of INT_MAX from <limits.h>?

$ cppawk '#include <limits.h>
> BEGIN { print INT_MAX }'
2147483647

Get it here: https://www.kylheku.com/cgit/cppawk/tree/

So, where is <limits.h>?

$ cppawk --prepro-only '#include <limits.h>
BEGIN { print INT_MAX }'
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "<stdin>"
# 1 "/usr/lib/gcc/i686-linux-gnu/7/include-fixed/limits.h" 1 3 4
[ ... ]
# 35 "/usr/lib/gcc/i686-linux-gnu/7/include-fixed/limits.h" 2 3 4
# 2 "<stdin>" 2
BEGIN { print 0x7fffffff }

The flags like "1 3 4" are meaningful. In particular, "1" means opening
a new file, and "2" means closing a file.

On 20/03/2022 16:04, Kenny McCormack wrote:

> If anyone here ... could explain to me what they think OP's actually
> problem is, I'd be most grateful.

I think Digi's scenario is that he is using AWK as a code generator to
create a dynamic piece of AWK code. The dynamic code is, I'm assuming,
mostly a framework with a bunch of @includes that are inserted by the
code generator. When the dynamic code is run the @includes pull in the
actual code and, hey presto, it all works.

To complicate things further, some of those @included libraries need to
read in a data file that is specific to the library in some way, and
held in the same source directory as the @include file itself.

Hence the request: if he could easily obtain the location of the
@included file then he could easily know where to read the data file.

If that is indeed the requirement then Manuel Collado's sample code that
checks for a file and get its path would do the job.

--
Bruce Horrocks
Surrey, England

On 2022-03-21, Bruce Horrocks <07.013@scorecrow.com> wrote:
> On 20/03/2022 16:04, Kenny McCormack wrote:
>
>> If anyone here ... could explain to me what they think OP's actually
>> problem is, I'd be most grateful.
>
> I think Digi's scenario is that he is using AWK as a code generator to
> create a dynamic piece of AWK code. The dynamic code is, I'm assuming,
> mostly a framework with a bunch of @includes that are inserted by the
> code generator. When the dynamic code is run the @includes pull in the
> actual code and, hey presto, it all works.
>
> To complicate things further, some of those @included libraries need to
> read in a data file that is specific to the library in some way, and
> held in the same source directory as the @include file itself.
>
> Hence the request: if he could easily obtain the location of the
> @included file then he could easily know where to read the data file.
>
> If that is indeed the requirement then Manuel Collado's sample code that
> checks for a file and get its path would do the job.

Referring to a data file adjacent to an include file is easily done
with cppawk, thanks to the C preprocessor's familiar __FILE__ built-in
symbol:

$ cat main.cwk
#include "subdir/helper.cwk"

BEGIN { helper_function() }

$ cat subdir/helper.cwk
function helper_function()
{
my_dir = __FILE__
sub(/[/][^/]+$/, "", my_dir) # strip off last component
print "my_dir = ", my_dir
}

Run it:

$ cppawk -f main.cwk
my_dir = subdir

See: helper_function in subdir/helper.cwk knows that its directory is
subdir. It could easily access a data file relative to that.

Plus you don't need any AWKPATH or its ilk, because ccp implements a
very useful requirement: the #include "..." directive looks first in the
same directory as the parent file in which that directive is found.

No matter from which location I invoke main.cwk, it will find
subdir/helper.cwk:

$ cd /etc
/etc $ cppawk -f /home/kaz/junk/cppawk/main.cwk
my_dir = /home/kaz/junk/cppawk/subdir

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

In article <20220321072908.947@kylheku.com>,
Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>On 2022-03-21, Mack The Knife <mack@the-knife.org> wrote:
>> This is similar to the code in the igawk.sh script which comes
>> with the gawk distribution. That program could easily be modified
>> to set up an array with the information that the OP desired.
>>
>> As such, it is rather unlikely that his requested feature would
>> be added to gawk itself.
>
>The new Awk with C Preprocessor (cppawk) solves the problem
>like this:

No, it doesn't, since the OP wanted access to the information from
within the running awk program.

On 2022-03-23, Mack The Knife <mack@the-knife.org> wrote:
> In article <20220321072908.947@kylheku.com>,
> Kaz Kylheku <480-992-1380@kylheku.com> wrote:
>>On 2022-03-21, Mack The Knife <mack@the-knife.org> wrote:
>>> This is similar to the code in the igawk.sh script which comes
>>> with the gawk distribution. That program could easily be modified
>>> to set up an array with the information that the OP desired.
>>>
>>> As such, it is rather unlikely that his requested feature would
>>> be added to gawk itself.
>>
>>The new Awk with C Preprocessor (cppawk) solves the problem
>>like this:
>
> No, it doesn't, since the OP wanted access to the information from
> within the running awk program.

Indeed, it may look like it because I didn't get into that in the
article you are responding to here, but in another article I showed how
interpolation of the familiar __FILE__ symbol allows any individual
included file to be informed of its own path name. From that, it can
calculate the directory name and access a data file in that same
directory.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

hello

sorry i have a lot of job last week.

i see in gawk manual 2.7 - there is a some recent changes about it...

and it describes exactly my case: many libraries, with a separate folder for each. and all these folders are located in one global folder. suppose I point the AWKPATH to this global folder. but i cannot performing @include by the filepath that is RELATIVE to AWKPATH:

- library's global folder (AWKPATH) is located at:

Directory of D:/a/ab/abc/mod/

02-Apr-22 03:04 <DIR> arr
27-Mar-22 20:20 <DIR> audio
27-Mar-22 20:20 <DIR> class
27-Mar-22 20:20 <DIR> core
27-Mar-22 20:20 <DIR> env
27-Mar-22 20:20 <DIR> gmatch
27-Mar-22 20:20 <DIR> grp
27-Mar-22 20:20 <DIR> io
27-Mar-22 20:20 <DIR> list
27-Mar-22 20:20 <DIR> mac
27-Mar-22 20:20 <DIR> mpu
27-Mar-22 20:20 <DIR> op
27-Mar-22 20:20 <DIR> other
27-Mar-22 20:20 <DIR> rexp
27-Mar-22 20:20 <DIR> rexp2
27-Mar-22 20:20 <DIR> smatch
27-Mar-22 20:20 <DIR> str
27-Mar-22 20:20 <DIR> term
27-Mar-22 20:20 <DIR> uid
27-Mar-22 20:20 <DIR> wav
14-Dec-21 03:24 13,369 _env.inc
27-Mar-22 20:20 <DIR> _grp

each folder is the library's folder that is typically contains library's source file for including:

Directory of D:/a/ab/abc/mod/arr/

30-Mar-22 16:35 117,290 _arr.mod
30-Mar-22 16:35 117,290 _arr.inc
30-Mar-22 16:35 117,290 _arr.mod.prev

- executing gawk script:

@include "arr/_arr.mod"

and FAILs because of the '/'-character is exist in the RELATIVE (by the actual) filepath.

situation. this leads that filepath for @include directive must be ALWAYS absolute. feature of the AWKPATH is completely isn't useful for me.

my current solution(windows) is making some network file share (env) that is using like AWKPATH do. all include directives then allows to be looks like:

@include "//env/mod/arr/_arr.mod"

ok. but this is not the all.

sometimes, included library contains nested includes. and these filepaths are also needs to be hardcoded. everwhere - there are only hardcoded filepaths:

@include "//env/mod/arr/_arr.inc"

this leads to many problems including such kind of questions like: portability ? multiplatforming? changing version of the librarys?

I was offering several solutions:

- environment variables are able to read in filepaths for @include:

like: %ENVIRON%

@include "%env%arr/_arr.mod"

- current folder for a subincludings located in a file - is the folder where this file is located:

...
@include "//env/mod/arr/_arr.mod"
...

_arr.mod:

...
@include "_arr.inc" # the path is the original's file (_arr.mod) folder: "%env%arr/"
...

as for the requested feature, I look even further than the described problems with include. it's about similar problems at the user level.

I think there is no need to describe all the cases why and when any library needs some kind of it's internal file. there are quite a lot of such cases.. I am sure that this question is clear to everyone. so as the result, we have the same hardcoded filepaths - but now also at the gawk user level.

that's the reason of requesting feature.

thnx)
D

On 03/04/2022 22:07, Digi wrote:
> hello
>
> sorry i have a lot of job last week.
>
> i see in gawk manual 2.7 - there is a some recent changes about it...
>
> and it describes exactly my case: many libraries, with a separate folder for each. and all these folders are located in one global folder. suppose I point the AWKPATH to this global folder. but i cannot performing @include by the filepath that is RELATIVE to AWKPATH:

That is correct. AWKPATH is only searched if the @include does not
contain a '/'.

>
> - library's global folder (AWKPATH) is located at:
>
> Directory of D:/a/ab/abc/mod/
>
> 02-Apr-22 03:04 <DIR> arr
> 27-Mar-22 20:20 <DIR> audio
> 27-Mar-22 20:20 <DIR> class
> 27-Mar-22 20:20 <DIR> core
> 27-Mar-22 20:20 <DIR> env
> 27-Mar-22 20:20 <DIR> gmatch
> 27-Mar-22 20:20 <DIR> grp
> 27-Mar-22 20:20 <DIR> io
> 27-Mar-22 20:20 <DIR> list
> 27-Mar-22 20:20 <DIR> mac
> 27-Mar-22 20:20 <DIR> mpu
> 27-Mar-22 20:20 <DIR> op
> 27-Mar-22 20:20 <DIR> other
> 27-Mar-22 20:20 <DIR> rexp
> 27-Mar-22 20:20 <DIR> rexp2
> 27-Mar-22 20:20 <DIR> smatch
> 27-Mar-22 20:20 <DIR> str
> 27-Mar-22 20:20 <DIR> term
> 27-Mar-22 20:20 <DIR> uid
> 27-Mar-22 20:20 <DIR> wav
> 14-Dec-21 03:24 13,369 _env.inc
> 27-Mar-22 20:20 <DIR> _grp
>
> each folder is the library's folder that is typically contains library's source file for including:
>
> Directory of D:/a/ab/abc/mod/arr/
>
> 30-Mar-22 16:35 117,290 _arr.mod
> 30-Mar-22 16:35 117,290 _arr.inc
> 30-Mar-22 16:35 117,290 _arr.mod.prev
>
> - executing gawk script:
>
> @include "arr/_arr.mod"
>
> and FAILs because of the '/'-character is exist in the RELATIVE (by the actual) filepath.

That is not correct. The @include does not fail because it includes a
"/" - it is failing because you do not have a subdirectory called "arr"
containing a file called "_arr.mod" **in the current directory**.

As the manual says (section 2.7) you can use relative paths using the ..
notation e.g. @include "../io_funcs". This will look in the parent
directory of the current one for a file called "io_funcs".

> situation. this leads that filepath for @include directive must be ALWAYS absolute. feature of the AWKPATH is completely isn't useful for me.

Strictly, for AWKPATH to be used then the @include name must be a
basename i.e. filename only without any path, neither absolute nor relative.

> my current solution(windows) is making some network file share (env) that is using like AWKPATH do. all include directives then allows to be looks like:
>
> @include "//env/mod/arr/_arr.mod"
>
> ok. but this is not the all.
>
> sometimes, included library contains nested includes. and these filepaths are also needs to be hardcoded. everwhere - there are only hardcoded filepaths:
>
> @include "//env/mod/arr/_arr.inc"
>
> this leads to many problems including such kind of questions like: portability ? multiplatforming? changing version of the librarys?

There are many, many potential problems relating to portability across
multiple platforms that GAWK does not try to prevent happening because
that's not GAWK's job.

If you need to write multi-platform code then you need to make sure your
source-code environment can be supported on all platforms. Similarly, if
you need to change libraries then you need to have a controlled
environment where library versions are carefully managed. There are many
ways of doing so but the solution is not through GAWK alone.

>
> I was offering several solutions:
>
> - environment variables are able to read in filepaths for @include:
>
> like: %ENVIRON%
>
> @include "%env%arr/_arr.mod"
>
> - current folder for a subincludings located in a file - is the folder where this file is located:
>
> ...
> @include "//env/mod/arr/_arr.mod"
> ...
>
> _arr.mod:
>
> ...
> @include "_arr.inc" # the path is the original's file (_arr.mod) folder: "%env%arr/"
> ...
>

All these ideas are potential options to be included in a future version
of GAWK. But GAWK isn't a place for any old extra feature - otherwise it
would be bloated. Only features that are likely to get regular use would
be worth including

> as for the requested feature, I look even further than the described problems with include. it's about similar problems at the user level.
>
> I think there is no need to describe all the cases why and when any library needs some kind of it's internal file. there are quite a lot of such cases. I am sure that this question is clear to everyone. so as the result, we have the same hardcoded filepaths - but now also at the gawk user level.
>
> that's the reason of requesting feature.
>
> thnx)
> D

--
Bruce Horrocks
Surrey, England

...All these ideas are potential options to be included in a future version
of GAWK. But GAWK isn't a place for any old extra feature - otherwise it
would be bloated.

i understand and that is exactly what i want, thank you =)

but I think I'm not the only one who offers to contribute some new features in gawk.
I am very interested to hear about this. is it possible to read such discussions?

may i offering another ideas?

is it good place for this ?

with Respect
Denis

[ I suggest to use a real newsreader to access Usenet newsgroups;
it helps you also with the quoting of information you refer to
in your posts. - Below I fixed it for you. ]

On 05.04.2022 15:46, Digi wrote:
> Bruce Horrocks wrote:
>> ..All these ideas are potential options to be included in a future version
>> of GAWK. But GAWK isn't a place for any old extra feature - otherwise it
>> would be bloated.
>
> i understand and that is exactly what i want, thank you =)
>
> but I think I'm not the only one who offers to contribute some new features in gawk.
> I am very interested to hear about this. is it possible to read such discussions?

Features have been discussed here in the past. Some requests (that
had been considered by the maintainers to make sense incorporating
into GNU Awk) have made their way into the code base. As was to
expect, many other requests or suggestions have not made it.

>
> may i offering another ideas?

It may help to read "B.4.1 Defining What Is and What Is Not A Bug"
in the GNU Awk manual, which (amongst the bug related stuff) says:

The following things are not bugs, and should not be reported
to the bug mailing list. You can ask about them on the “help”
mailing list (see section Where To Send Non-bug Questions),
but don’t be surprised if you get an answer of the form
“that’s how gawk behaves and it isn’t going to change.” [...]

Missing features, for any definition of feature. [...]

The number of features that gawk does not have is by definition
infinite. It cannot be all things to all people. In short,
just because gawk doesn’t do what you think it should, it’s
not necessarily a bug.

I suppose you understand that stance (also WRT features).

>
> is it good place for this ?

Basically yes. It's in your interest that the intention is clear,
that it's well described, and not just Yet Another Nice Feature
idea.

Depending on the type of the feature there's also the possibility
that you write functionality you desire using the Gawk mechanism
"Extension Library". That way it's decoupled from awk's core code
and quality and usefulness of your library will show whether it
gets used or not. Good coding skills and design experiences are
mandatory to be successful, I'd say.

Apart from that mechanism (and provided that a feature request
makes sense); providing quality code for it likely increases the
chance to get added.

A clear feature concept and clear sample code is also a good
base for a discussion here.

Janis

>
> with Respect
> Denis
>
>
>
>