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

Command-line arguments are not passed on macOS #12

Closed
wesleycoder opened this issue Apr 7, 2019 · 6 comments
Closed

Command-line arguments are not passed on macOS #12

wesleycoder opened this issue Apr 7, 2019 · 6 comments
Labels
bug 💵 Funded on Issuehunt This issue has been funded on Issuehunt help wanted

Comments

@wesleycoder
Copy link

wesleycoder commented Apr 7, 2019

Issuehunt badges

I use this cli to pass args via npm scripts like:
opn http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876
But on MacOS Mojave it doesn't works, I think it is because the browser is named diferently on the OS.

But even when passing:
opn http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876
The browser doesn't start.
Calling opn http://localhost:4200 -- 'Google Chrome' it opens the browser.

My necessity is to open another instance of the browser with a profile scoped to the .tmp-chrome folder.

I've wrote a simple script as a workaround to use on my project, but I think this package could solve this problem more elegantly.

#! /usr/bin/env node
const opn = require('opn')
const childProcess = require('child_process')

const plat = process.platform

if (plat === 'darwin') {
  const cp = childProcess.spawn(
    '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
    [
      '--user-data-dir=.tmp-chrome',
      '--remote-debugging-port=9876',
      'http://localhost:4200',
    ]
  )

  cp.unref()

  process.exit(0)
} else {
  const browser = plat === 'win32'
    ? 'chrome'
    : 'google-chrome'

  opn('http://localhost:4200', {
    wait: false,
    app: [
      browser,
      '--user-data-dir=.tmp-chrome',
      '--remote-debugging-port=9876',
    ],
  })
}

There is a $40.00 open bounty on this issue. Add more on Issuehunt.

@IssueHuntBot
Copy link

@IssueHunt has funded $40.00 to this issue.


@issuehunt-oss issuehunt-oss bot added the 💵 Funded on Issuehunt This issue has been funded on Issuehunt label May 10, 2019
@sindresorhus sindresorhus changed the title Command line arguments are not passed on MacOS Command line arguments are not passed on macOS May 13, 2019
@sindresorhus sindresorhus changed the title Command line arguments are not passed on macOS Command-line arguments are not passed on macOS May 13, 2019
@ankurkaushal
Copy link

@wesleycoder For some reason I couldn't reproduce some of the scenarios you mentioned in the issue:

  • open-cli http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Doesn't work as expected.
  • open-cli http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Works
  • open-cli http://localhost:4200 -- 'Google Chrome' --> Works

I am on Mac OS X Mojave (10.14.5) too.

May be I am unsure of what you're expecting open-cli to do, can you explain? :)

@wesleycoder
Copy link
Author

open-cli http://localhost:4200 -- 'google-chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Doesn't work as expected.

  • This will not work cross environments because open-cli doesn't know how to deal with differences between OSs on the binary name, and maybe would be possible to implement it.

open-cli http://localhost:4200 -- 'Google Chrome' --user-data-dir=.tmp-chrome --remote-debugging-port=9876 --> Works

  • This should start the google-chrome browser with a blank profile saved to a .tmp-chrome on the current working directory and with the remote debugging port set to 9876, but instead it opens a new window on the current profile of the browser because open-cli doesn't pass the -- parameters to the google-chrome instance upon starting correctly.
    The code snippet on the issue descriptions does this with the opn lib.

open-cli http://localhost:4200 -- 'Google Chrome' --> Works

  • This will work ok since we are passing the name of the binary correctly and no cli flags.

Let me know if I can provide more info or help with anything.
Thanks for looking into the issue.

@dfahlander
Copy link

I have the same issue. The issue seems to be, at least for the --incognito argument, it has to be passed differently to the native "open" cli on Mac in order to be respected.

The current libary uses "open" library that calls the native "open" CLI on mac as follows:

open -a "Google Chrome" "http://localhost:4200" "--incognito"

But in order for --incognito to be respected, one has to start a new instance and pass the URL among the arguments instead:

open -na "Google Chrome" --args "http://localhost:4200" "--incognito"

I was about to fix this in the source but I'm out of time as it also would require a change on the "open" package that this depends on.
In my case I could fix it using a custom CLI. But if anyone else is eager to fix this, look in the open library on index.js, lines 51-63 where it pushes arguments to the native open. That library would need to be extended to allow "-na" flag instead of "-a" and then this library could use that argument and pass the URL among the arguments instead.

@itaisteinherz
Copy link

@dfahlander Seems like sindresorhus/open#253 added the option required in order to fix this in the CLI, right?

@wesleycoder
Copy link
Author

This is not relevant for me anymore and since there was no activity for a long time I'll be closing this PR so it clears out of the pile.
If needed feel free to open another PR and mention this to keep track of the history if relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 💵 Funded on Issuehunt This issue has been funded on Issuehunt help wanted
Projects
None yet
Development

No branches or pull requests

6 participants