Recent changes to 12: tkdiff message Files are Identical

#12 tkdiff message Files are Identical

2023-09-30T15:50:39.568000Z

Well, my reading of that recommendation, is you do that if you REQUIRE a specific SHELL to process the request. I suppose I could go look at the TCL SrcCode at how "exec" is implemented, but given that the user can cause the problem to disappear by changing the choice of SHELL in his environment, I'm fairly certain TCL is making use of it. That wouldn't logically happen if it always used /bin/sh.

But the TCSH error report did talk about the rather odd (to me) arrangement of builtin Vars (status, anyerrors) it uses to convey exitcodes back to the caller. The other Shells simply use the "?" Var for that, but in TCSH "?" is supposedly an alias to "status". Is it possible that alias is maybe MISSING in the users environment, and THAT's the reason we see a ZERO?

I realize its a really old BUG, but there is no telling how "up-to-date" the user environment is. I mean we still have people downloading ancient versions of TkDiff because their Sys-Admins claim they must maintain a "matching" environment for the user community.

Combine that with the time it takes for releases to migrate out into the world, and that it might involve releases of both TCSH and/or TCL (because we don't know if TCL ever CHANGED because of the BUG or its later fix). It's not impossible for years to have passed. The bugzilla report discussion mentions the TARGET version of TCSH where the resolution was expected to appear, but who knows if that actually happened?

#12 tkdiff message Files are Identical

2023-09-29T06:12:34.694000Z

Wait, I thought tcl exec ignored the user's shell, and would always use /bin/sh unless you do something like "exec $env(SHELL) ..."
This page https://www.tcl-lang.org/man/tcl/TclCmd/exec.htm recommends that, if you want to pipe data generated in tcl to a shell command. The way I understood it, it shouldn't be dealing with the user's shell at all. But I'm notoriously careless about such things, so I could well be wrong.

#12 tkdiff message Files are Identical

2023-09-29T05:15:40.403000Z

Thanks for the extra info. Not sure how much it helped, BUT....

As Dorothy commented, TCSH itself isn't NECESSARILY the problem (she notes zero issues). This suggests (as she indicated) an "environmental" issue peculiar to your machine(s).

And this is where things could get "sticky" - given something I stumbled across (thanks to Google). I found an old(er) RedHat bugzilla report (circa 2012, number 638995) that indicated an unfortunate patch in TCSH itself regarding how the exit code of a Shell command was being handled. And it gets worse when one considers that TCL (the language TkDiff is written in) is itself yet ANOTHER software layer between the TkDiff code and things that can be requested of the underlying OS.

First - the way things are SUPPOSED to happen, TkDiff forms a command to invoke "diff" with appropriate arguments, then PASSES this command to a TCL builtin function asking for it to be run as a Shell Command pipeline, requesting the EXITCODE be returned (along with BOTH the StdOut and StdErr filestreams). If that exitcode is ZERO - then there were NO differences and TkDiff proceeds to claim "Files are identical". When NOT, the text streams are parsed and the text windows get marked up. For the record, exitcodes less than zero OR greater than one are considered BAD errors, while a "one" simply means differences were found.

BUT - the syntactic method of obtaining said EXITCODE is different - because TCSH is not BASH (or KSH, or BOURNE, etc.) This suggests that TCL must be aware of what Shell is being passed the command, and to adjust as-needed to provide the defined semantics of the builtin TCL command "exec" used to invoke the Shellcmd. Thus TCL clearly becomes involved. But as Dorothy noted, it is not impossible for TCSH to handle this correctly.

However, the BUG report indicates that somewhere along the line, TCSH made a syntactic modification in HOW a reliable exitcode is to be obtained, and subsequently was forced to RETRACT their change at some further point in time. SO NOW we have a potential issue having TWO possible inflection points:
1. when did TCSH make the first change and how long did it take for TCL to 'catch up' to that modification and adapt? And
2. when did TCSH revert (or patch, or whatever) their mistake, how many releases had gone out in the bad state, and when did TCL again catch up? (assuming it ever changed at all).

SO - this could be a question of what version of TCL is in use, PLUS what version of TCSH is in effect, And worse yet, ALL THIS is peculiar to YOUR machines! AND this could all be a red herring, and have nothing to do with what is happening, assuming your systems are more recent than all this, say perhaps versions within the past five years (thus allowing for potential mis-matches to have normalized themselves out over the past decade).

I cant say this IS your problem, but the bug report describes a situation where the exitcode was ALWAYS reporting as ZERO, regardless of whether the command had actually returned some other value. I swear - I'm not making this up!!

Perhaps you could try running just a commandline "diff" (eg. eliminate TkDiff altogether) and determine if your TCSH can EVER report a ZERO exitcode despite printing actual differences? My understanding of the Bug report (which you might wish to read - link provided above) is it involved whether some "escape mechanism variable (anyerror)" is set BEFORE running the command and then looking at a different variable(status) for the exitcode - or something like that -- I re-iterate I'm no TCSH expert, so I'm hoping this makes more sense to you. I'm uncertain how much I can suggest beyond this as I don't have your system on which to test, unless you want to dig into the TkDiff code yourself. I can certainly tell you WHERE to look.

#12 tkdiff message Files are Identical

2023-09-28T16:16:16.869000Z

attachment for previous posting. Where it says Attachment: tkdiff works

#12 tkdiff message Files are Identical

2023-09-28T16:13:16.553000Z

Thank you for the reply, and fair enough on requiring more information. Let me try to outline my scenario a little more detailed here.
1. Same server my id is configured with administration rights and user is not.
2. Tkdiff was loaded on a network share and local disk on node with same results for the user “files are identical”
3. How, I execute program from either “network or local disk” location:
./tkdiff CHANGELOG.txt README.txt &
Attachment: tkdiff_works

As you can see from above the results return as expected.
Here is my shell setting on this node: echo $SHELL ---/bin/bash

Location of the files: pwd ----/prj/avnera/tools/tkdiff-5-6
Again I receive the same results when executing “tkdiff” from local disk on the node itself.

Here is what I’m describing as I execute “tkdiff” between the same files as the user ID.
User shell: echo $SHELL -----/bin/tcsh

Command executed, same as above: ./tkdiff CHANGELOG.txt README.txt &

Attachment: tkdiff_not_working

As you can see above same command executed against the same files and it doesn’t work.

I even copied the files to local /tmp/ directory and “chmod 755 and chown” all the files and directory with the user ID and groups membership and still didn’t work?

-rwxrwxrwx 1 userid group 21097 Sep 25 07:31 CHANGELOG.txt
-rwxrwxrwx 1 userid group 18092 Sep 25 07:31 LICENSE.txt
-rwxrwxr-x 1 userid group 97 Sep 27 07:20 test1.txt
-rwxrwxr-x 1 userid group 336 Sep 27 07:21 test2.txt
-rwxrwxr-x 1 userid group 880596 Sep 25 07:33 tkdiff

Not sure what else I’m missing here. Additional library required or if there is something invoked in the background that need permissions adjusted?

#12 tkdiff message Files are Identical

2023-09-28T05:47:55.854000Z

I use tcsh so I can attest that it works fine. But since it seems to be related to environment, it makes me wonder if you have an alias for "diff" that invokes it with some options or something.

#12 tkdiff message Files are Identical

2023-09-28T03:59:38.839000Z

Ummm, OK - but your description is a bit vague.

For one you neglected to supply HOW you were invoking the tool (what does your commandline look like?). You suggest that done thru BASH all is OK, but thru TCSH it 'fails'; but TECHNICALLY speaking "Files are identical" is merely a STATUS message - not a failure. Yet I'll presume you have actually provided some kind of filenames OF WHICH you honestly believe differences SHOULD occur. Perhaps a larger snapshot would have conveyed more information? For example, the two filenames being compared are displayed above the windows that depict the files themselves. Are those names actually DISTINCT? What was meant by "nothing happens"?

That you got THAT status message implies the tool completed what was asked of it, and this was simply the RESULT - Be advised that internally, TkDiff invokes a Diff command (THRU whatever SHELL is in force). I'm no TCSH expert, but to my knowledge, we aren't playing any exotic games in FORMING the command to be run with any syntax beyond a "command" word, some "possible" options (eg. "-x name" or similar), followed by TWO filenames. I don't see any particular reason why TCSH would necessarily corrupt the output results ATTRIBUTABLE to TCSH. I understand TCSH is not BASH, and I'm not suggesting your problem is not real, just that I cant investigate with next-to-zero information.
Would you care to supply/attach additional info?

tkdiff message Files are Identical

2023-09-26T14:31:06.390000Z

I've installed tkdiff application and when I execute the command to detect differences between files. Nothing happens and I receive a message at bottom left hand corner that "files are identical"? Am I missing any additional prerequisites for this application to function properly? Is there a permission issue. Funny part is that as root "bash" shell it works fine. However, users with "tcsh" shell they receive this message?