Skip to content
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

Using UTF-8 characters crashes project generation #171

Closed
Legoless opened this issue Sep 2, 2014 · 18 comments · Fixed by #182
Closed

Using UTF-8 characters crashes project generation #171

Legoless opened this issue Sep 2, 2014 · 18 comments · Fixed by #182
Labels

Comments

@Legoless
Copy link

Legoless commented Sep 2, 2014

When using UTF-8 characters such as midpoint ·, liftoff crashes during project generation. For example I use our company name D·Labs when generating the project and it crashes with:

/usr/local/Cellar/liftoff/1.3/rubylib/liftoff/project_configuration.rb:72:in `gsub': invalid byte sequence in US-ASCII (ArgumentError)
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/project_configuration.rb:72:in `normalized_company_name'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/project_configuration.rb:42:in `company_identifier'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/option_fetcher.rb:17:in `public_send'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/option_fetcher.rb:17:in `fetch_option_for'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/option_fetcher.rb:10:in `fetch_options'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/launchpad.rb:24:in `fetch_options'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/launchpad.rb:9:in `liftoff'
    from /usr/local/Cellar/liftoff/1.3/rubylib/liftoff/cli.rb:10:in `run'
    from /usr/local/bin/liftoff:14:in `<main>'
@gfontenot
Copy link
Member

Good to know. This has to do with the normalization when we generate the default company identifier for the bundle identifier. I'm assuming you'd expect to have all non-ascii characters stripped here?

@Legoless
Copy link
Author

No, I would like to keep them, as our official company name uses a midpoint.

@gfontenot
Copy link
Member

Have you been able to use that midpoint inside your current bundle identifiers?

@Legoless
Copy link
Author

Sorry, you are correct, we do want to strip that from bundle indentifiers, but keep it for company names.

@gfontenot
Copy link
Member

👍 This normalization (which is the crash you're seeing) is only used for the bundle identifiers. Everything else is left as-is.

@gfontenot
Copy link
Member

@Legoless I'm actually not able to reproduce this locally. Can you give me more information about your setup?

@Legoless
Copy link
Author

I am still able to reproduce this. As soon as I enter a midpoint (·) in "Company name" when calling "liftoff", the app crashes with the above error. If no midpoint is used, the app works correctly with the same setup.

@gfontenot
Copy link
Member

@Legoless I really need more information than this. I can't reproduce this at all.

@Legoless
Copy link
Author

The problem is still here in 1.4.1:

Project name? Project     
Company name? D·Labs
/usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/project_configuration.rb:83:in `gsub': invalid byte sequence in US-ASCII (ArgumentError)
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/project_configuration.rb:83:in `normalized_company_name'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/project_configuration.rb:45:in `company_identifier'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/option_fetcher.rb:17:in `public_send'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/option_fetcher.rb:17:in `fetch_option_for'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/option_fetcher.rb:10:in `fetch_options'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/launchpad.rb:34:in `fetch_options'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/launchpad.rb:12:in `liftoff'
    from /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff/cli.rb:10:in `run'
    from /usr/local/bin/liftoff:14:in `<main>'

In addition to this, it is set to Objective-C (objc). I believe the error is in the normalization function before you ask for company identifier, which displays a normalized one in addition to asking the user for it. Is there any more information you need?

configure_git: false
warnings_as_errors: true
enable_static_analyzer: false
indentation_level: 4
use_tabs: false
use_cocoapods: true
strict_prompts: false

@gfontenot
Copy link
Member

@Legoless Can you please tell me what version of OS X you're running as well as the output of /usr/bin/ruby -v?

@gabebw
Copy link
Contributor

gabebw commented Oct 15, 2014

@Legoless Also, can you show what the output of this is?

echo $LANG
echo $LC_ALL
echo $LANGUAGE

Does the problem go away if you do:

export LANG=en_US.UTF-8 LANGUAGE=en_US.UTF-8 LC_ALL=en_US.UTF-8

then run liftoff?

@gabebw
Copy link
Contributor

gabebw commented Oct 15, 2014

I suspect that @Legoless has $LANG set to sl-SI.UTF-8 (Slovenian). If I do export LANG=sl-SI.UTF-8, I get exactly the same error.

@Legoless
Copy link
Author

The version of Ruby I am running is (OS X Yosemite):

ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin14]

@gabebw That export does seem to fix the problem. Funny thing is that I do not even have these variables set (I'm using zsh).

@gfontenot
Copy link
Member

@Legoless I believe I have a fix for this with #182. If you'd like you can make this change locally (located at /usr/local/Cellar/liftoff/1.4.1/rubylib/liftoff) until I send out a fix for this.

@Legoless
Copy link
Author

@gfontenot Thanks, will do!

@gfontenot gfontenot added the bug label Dec 5, 2014
@gfontenot
Copy link
Member

@Legoless Did you try the hot-fix? Can you confirm that if fixed this issue?

@gfontenot
Copy link
Member

Unless I hear otherwise, I'm going to assume that this is fixed by #182

@Legoless
Copy link
Author

Legoless commented Dec 7, 2014

Sorry for taking so long to get back to you. Issue appears to be fixed here, I figured you had closed this because of that. :)

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

Successfully merging a pull request may close this issue.

3 participants