SED does not produce output within SH on X5000 but does with X1000 [SOLVED]

I have the following script:


I have the same version of all of the programs being used in the script. And I find my self in the same old situation again: "It works on the X1000, but not the X5000!?"

If I go into some root project directory with source files and run "ctags" on the X1000, I get my CTAGS all populated and ready, on the X5000 with the very same script, with the very same tools, at the very same versions, I just get the top 6 lines of CTAGS meta-data!

Can someone else try this. You will just need to run protect +s and also install ctags (OS4Depot) and change the LOC of your ctags accordingly.

I just love these WTH moments.

==

So far, on the X5000 when I break things down, it seems to be the SED script that fails on the X5000, yet it works on the X1000 .... :S

==

I also I am not interested in improvements or questions of why I am doing things a certain way. By all means, lecture me later, I just firstly want to know why there is a difference here.

Okay, well... for whatever reason the issue seems to be running SED within SH.

I can run that SED within Amiga "Shell" on both machines, and I get the same results, but, within Amiga "Shell" -> within "SH" -> running SED produces no output on my X5000, but it works on the X1000.

My reproducible steps are:

1 - Copy the following contents into any file:


2. CD into the directory containing that file

3. run the following command in Amiga Shell:


4. See that the output is:


5. From that shell, no go into "SH" by executing:


6. Run the same SED command:


7. Notice that there is no output

===

Wondering if anyone else can agree with my Step 7. On my X1000 step 7 produces the same output as step 4.

The file sizes and versions of SH and SED are the same on both machines.

What is also interesting is that the X1000 opens up:



Where as the X5000 opens up:



This was checked using Snoopy.

Okay, that seems to be it.

For whatever reason, in within SH within Amiga Shell on the X5000, SED is opening up "newlib". When running SED just withing Amiga Shell it opens up "utility" and "dos".

On the X1000 it opens up "utility" and "dos" no matter if just running through Amiga Shell or Amiga Shell->SH.

At this point, I need someone more qualified than me to explain why this is happening.

Okay, what an ordeal.

So, when in SH on the X5000 I noticed - thanks to Snoopy - that it was running SED from AmiCygnix instead of the one in the SDK which is very interesting because when in SH:

Bring back:

I am afraid that is lies, and not how "which" should behave.

Returns:


And, "sed" is in "/Cygnix/CygnixPPC/bin/sed" before "/SDK/Local/C".

So now, I guess we cannot trust even "which".

===

Edit: Actually, "which" is an Amiga program, so when I said "not how which should behave" I assumed I was using a linux version of which.

===

Okay, wow.

The reason "which sed" is bringing back SDK/Local/C is because - yes, it is the Amiga version, and for me, the SDK/Local/C is BEFORE the AmiCygnix WITHIN the Amiga environment context (i.e. typing "PATH" in AmigaShell)

It was kind of my mistake. I forgot that "which" was not a core-utils thing, and it is an Amiga application.

So - finally - all of this makes sense!

===

Now, I need to figure out where SH gets its PATH from, and why the Amiga path is not honoured.

@rjd324

The Amiga version of Which supports the ALL switch which will show you all the instances of the program in question, listed in the order they are found in the (AmigaOS) search path. When in doubt, I find this useful to check whether you do actually have the version you thought, but later in the path.

As for sh's path, I believe it is using the $PATH variable and not the AmigaOS path. Not sure how the initial contents of $PATH are set in a standard SDK installation.

Best regards,

Niels

@nbache

Thank you. I will remember that.

A little bit late, but this was solved over 3 years ago when I talked to @cygnused.

AmiCygnix was using the same version of SED as the one from the SDK, but it was compiled with a different C library and so the underlying implementation was different and thus causing the difference.

I now always ensure to prefer the SDK's binaries over AmiCygnix - not because one is better than the other, but just for consistency.

@rjd324

Yes, it was not my best idea to override the binaries of the SDK by AmiCygnix binaries without warnings. I will try to remove this in my next AmiCygnix release.

You can prevent this, when the AmiCygnix startup in the user-startup is called before the SDK startup.

The binaries of AmiCygnix 1.6 did not work correctly, but this was solved in V1.7. Now it is version 4.8 of sed and the parsing of the commandline arguments was fixed as newlib failed here.

For myself I prefer the AmiCygnix version, as the binary in the SDK sometimes crashes with large arguments. But I can understand, that you want to use the official ones.