good idea Kevin, that thread was getting pretty long.
Anyway, I did another run with your script and it is down to 18 so called dupes now but I don't think they are really dupes.
One of them for instance is the saulgoode calendar and the saulgoode year calendar, they are two different scripts, but come up as dupes. one is to make a monthly calendar and the other one a yearly one. Not a big deal as long as I know what they are.

Other than that I think the script is ready for launching, very good job.

here are the three calendar scripts and they are all different. I remember when he wrote them and they come up as dupes when I run the script.

sg-calendar.scm
sg-calendar-year.scm
sg-platonic=calendar.scm

This is were good programming practice comes into play. I went to school to be a COBOL programmer but alas no jobs when I got out. That's why I'm just a lowly mainframe operator and a novice PHP programmer of sorts (I'm ok at taking others code and just twisting it around for my needs ).

The fellow who wrote those scripts probably used his first and then just added on and saved with a different name. Which is not a good thing to do!

I'm about to dive into this today and start adding the scripts back in one at a time. There scripts I have that were taken from the orig in Gimp and then enhanced by somebody else without changing the registration or menu names. Not a good thing to do again!

I really need to learn how to write these scripts! I'd probably be half way descent at it .. but I need that one on one training.

Good idea open a dedicated topic to the script , was too hard trace it along the original help topic...and good idea the script too very useful, it is really a pain search manually for duplicated scripts that may have very different file names

thank Paynicky

If you have the latest version of 'sg-calendar.scm' then the 'sg-calendar-year.scm' file is not needed (as both commands are provided in the file).

Please delete the file 'sg-calendar-year.scm' and ensure you are using the latest version of 'sg-calendar.scm'.


If I recall correctly, the calendar-year script was written over a year after the calendar script was
released and in its initial beta form was a separate file requiring that the calendar script also be installed. During the development of the "year" script -- a process based largely on interaction with and feedback from the members of this forum -- it became expedient to combine the two files into one for technical reasons. The existence of 'sg-calendar-year.scm' on molly's computer is a remnant of her having participated in that development process; it does not belong there.

The 'sg-platonic-calendar.scm' file is an exceptional case. It is an optional adjunct to the 'sg-calendar' script. If installed, it requires 'sg-calendar.scm' to also be present (and thus there should be no conflict with both scripts being installed simultaneously). It is currently the only script I've published that depends upon resources not available with a default GIMP install. While the platonic script could be re-written to avoid this dependency, both scripts are already quite large by Script-fu standards (an order of magnitude larger than typical) and given the rather singular purpose of the platonic script, it would not be justified to either double the size of the calendar script or to maintain code redundancy in two separate scripts.

thank you saul, I knew there was the three but didn't know I had an antique in the midst. lol

Thanks Kevin.

It would be even better if a script could utilize grep to check additionally for author/function names or register info because most FX scripts do not use identical script names.

I've got about 15 duplicates this script did not find. (It did not find ANY scripts at all) If this script is suppose to be catching scripts by the register function names (e.g. "script-fu-drop-shadow"), it's not working for me. Most register information has the author's name, the date the script was written, etc. Not clear why the most obvious isn't obvious to you, but if the script could exceed just looking for function names, it could be beneficial in rounding up scripts by author, etc.

Script names = the name of the script.scm

Thank you. (script name=file name) I've just found that it doesn't work on Linux thanks to a difference in how the script-fu-paths are stored in gimprc. Windows uses a semi-colon to separate the paths and Linux uses a colon.

It might be helpful if a MAC user could type the following into the Script-Fu console and let me know what it displays:


As a quick fix you could find this line:


and change it to


At the moment I can't find an equivalent to DIR-SEPARATOR to give me a platform independent way for breaking up the path.

Kevin

Ah! I never thought outside the OS box, since I am using Ubuntu, thanks for the heads up.

Now another question, can you have this script create a log file so I can print out the list and double check?

Wow, a good question.

Well, I was thinking the directory path of the duplicates is what I wanted. But the reason I wanted author info as well is because some people rename scripts as their own, when they are in fact NOT the original author. I was intending to remove duplicate files and rename the files to reflect the author/script.

I hate countering with another question, but without providing both file names, how else would I know what it's duplicate file is, if I have nothing to compare it to? I have a tendency to shy away from the global GIMP share folders and want to organize my single user share folders. I slightly alter register function names to avoid the GIMP warnings (99% are FX scripts), so I want to root those out and stop my bad behavior and clean up and organize my single user shares, while removing those damn FX scripts.

I'll elaborate more if none of the above made any sense.

Just to be sure I understand, you saw messages in the error console for 2.6.11 but NOT on so called 2.7.4 ?

and @mahvin: Your explanation makes sense. I think I understand your requirement.

Kevin

Here's a beta of version 1.3

I think I've bodged it sufficiently to work on Windows and Linux (Need a Mac tester please)

There is now the option to create a log file of either just the duplicates, or of everything tested. the log file should appear one directory up from the .gimp directory, which might be your home directory on Linux and somewhere else on Windows.

Let me know what happens

Kevin

Update: We reached version 1.5, which is now on GimpScripts, see first post: viewtopic.php?f=9&t=3057&p=38900#p38900

Kevin, is this script in place of the previous one? Do I delete the one I have now before installing this one?

Yes you do replace the old one, otherwise it will end up reporting itself as a duplicate