tkdiff message Files are Identical

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?

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.

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.

1. 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.

1. 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?

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

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.

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.