Skip to content

Use of uninitialized value $less_charset in pattern match #400

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
felsenhower opened this issue Mar 31, 2021 · 17 comments
Closed

Use of uninitialized value $less_charset in pattern match #400

felsenhower opened this issue Mar 31, 2021 · 17 comments

Comments

@felsenhower
Copy link

I am trying to use diff-so-fancy on a system with macOS (Darwin 19.6.0), perl v5.18.4 and git version 2.24.3 (Apple Git-128).
When using it normally (like diff -u f1 f2 | diff-so-fancy), everything seems to be in order. But when setting up git like specified in the README, I get the following:

$ git diff     
Use of uninitialized value $less_charset in pattern match (m//) at /path/to/diff-so-fancy line 530, <STDIN> line 28.

This happens in the function should_print_unicode. I was trying to work around the issue by returning 0 or 1 in the first line of te function, which only leads to the following message:

$ git diff
"my" variable $columns_to_remove masks earlier declaration in same scope at /path/to/diff-so-fancy line 568.

Is this a problem with the installed dependencies or rather with diff-so-fancy?

@scottchiefbaker
Copy link
Contributor

This is almost certainly an issue with d-s-f. What version do you have? We fixed a less bug not to long ago I wonder if you have an old version.

@felsenhower
Copy link
Author

I am using the newest commit on master e5bddde

@scottchiefbaker
Copy link
Contributor

Can you give me the output of diff-so-fancy --debug please?

@felsenhower
Copy link
Author

It seems like the output is identical to the output of when I start d-s-f without parameters:

$ diff-so-fancy --debug
Diff-so-fancy: https://github.com/so-fancy/diff-so-fancy
Version      : 1.4.0

Usage:

git diff --color | diff-so-fancy         # Use d-s-f on one diff
cat diff.txt | diff-so-fancy             # Use d-s-f on a diff/patch file
diff -u one.txt two.txt | diff-so-fancy  # Use d-s-f on unified diff output

diff-so-fancy --colors                   # View the commands to set the recommended colors
diff-so-fancy --set-defaults             # Configure git-diff to use diff-so-fancy and suggested colors
diff-so-fancy --patch                    # Use diff-so-fancy in patch mode (interoperable with `git add --patch`)

# Configure git to use d-s-f for *all* diff operations
git config --global core.pager "diff-so-fancy | less --tabs=4 -RFX"

# Configure git to use d-s-f for `git add --patch`
git config --global interactive.diffFilter "diff-so-fancy --patch"

@scottchiefbaker
Copy link
Contributor

Are you sure you have the latest from master? There should definitely be --debug output. That's really weird.

Why don't you try the next branch and see if that fixes your problem?

@scottchiefbaker
Copy link
Contributor

For the record you should see something like this:

bakers@yellow(~/github/diff-so-fancy)
:./diff-so-fancy --debug
Diff-so-fancy   : v1.4.1
Git             : v2.27.0
Perl            : v5.26.3

Terminal width  : 187
Terminal $LANG  : en_US.UTF-8

Supports Unicode: Yes
Unicode Ruler   : Yes

Less Charset Var: LANG
Less Charset    : en_US.UTF-8

Is Windows      : No
Operating System: linux

@felsenhower
Copy link
Author

Yep, I'm pretty sure I was on the master branch. but now that I switched to next I can't reproduce the bug anymore, so it could be fixed. But diff-so-fancy --debug still produces nothing like you specified above. So maybe that's a second bug :)

@scottchiefbaker
Copy link
Contributor

Line 57 should call show_debug_info() which is defined at line 935. Do you not have that?

@felsenhower
Copy link
Author

Well, I'm not a Perl Pro, but the source looks like you described. However, modifying the source around Line 57 like this

if ($args->{debug}) {
        print "Hey!";
        exit();
}
print($args->{debug});

yields the following:

$ diff-so-fancy --debug                                             
Use of uninitialized value in print at /Users/rfelgenh/.local/bin/diff-so-fancy.d/diff-so-fancy line 60.

So I guess the debug flag is never set. I can also reproduce that on other machines.

@scottchiefbaker
Copy link
Contributor

Well maybe I can dig some more then... what OS are you using, and what version of Perl?

@felsenhower
Copy link
Author

Apart from the system mentioned at the very top, Manjaro Linux with perl v5.32.1.

@felsenhower
Copy link
Author

I figured out that --debug not working was a fault on my end. The output is now

$ diff-so-fancy --debug
Diff-so-fancy   : v1.4.1
Git             : v2.24.3128
Perl            : v5.18.4

Terminal width  : 150
Use of uninitialized value $ENV{"LANG"} in concatenation (.) or string at /path/to/diff-so-fancy line 946.

Alternatively:

$ LANG=C diff-so-fancy --debug
Diff-so-fancy   : v1.4.1
Git             : v2.24.3128
Perl            : v5.18.4

Terminal width  : 150
Terminal $LANG  : C

Supports Unicode: Yes
Unicode Ruler   : Yes

Less Charset Var: LANG
Less Charset    : C

Is Windows      : No
Operating System: darwin

Looks like the mac is weirdly set up and otherwise everything is okay.

@scottchiefbaker
Copy link
Contributor

I'm not a shell expert, but I think $LANG needs to be set to SOMETHING so the shell knows how to order things, and handle unicode stuff. The issue here is that the lack of a $LANG value of any kind is preventing d-s-f from knowing if your terminal supports UTF-8 or not.

@ericbn
Copy link
Contributor

ericbn commented May 8, 2021

As far as I've tracked this, the issue was introduced in 75587c6. The function get_less_charset now returns a tuple. But it does return (); (instead of return ("", "");) when no env variables are found, hence making the pattern match my ($less_env_var, $less_charset) = get_less_charset(); fail because the tuple is empty in this case.

I've mentioned I'm fixing this in #398.

@scottchiefbaker
Copy link
Contributor

This should be fixed on the next branch...

61bbdf7 and 9caa68e landed to address this.

@ericbn
Copy link
Contributor

ericbn commented May 12, 2021

Sorry about the confusion I've made around the fix for this. I didn't notice it was fixed in the next branch.

@scottchiefbaker
Copy link
Contributor

Closing this because it should be fixed on the latest version. If you still get the error let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants