$ not open config.yml on Windows

[michelepagot]

I'm using lazycli 0.1.14 on a Windows10 machine. I do not have any default association for the .yml files. So, for example, if I try to

start C:\Users\me\AppData\Roaming\lazycli\config\config.yml

I get nothing but a OS popup that asks me to suggest my preferred application to edit the .yml files

So within lazycli, $ has no effects at all, the low status bar quickly toggles between two messages, so the first one about "I'm using start" is barely visible. The Windows popup about file association does not appear when "start" is called by lazycli

Code behind it seems like

11	#[cfg(target_os = "windows")]
12	pub fn open_command() -> String {
13	String::from("start")
14	}

Unfortunately, I have no proposal about how to handle this situation or even if it has to be handled at all or code is fine like it is right now:

• maybe using dear old notepad ?
• maybe provide an environment variable to let the user to select its editor
• maybe just try to figure out that nothing happened with "start" and try to better prompting that user?

in any case, lazycli is a cool small doing one thing command: greater job

[jesseduffield]

@michelepagot would you be able to see if this branch fixes your issue? https://github.com/jesseduffield/lazycli/pull/13

[michelepagot]

Test performed.

Initial condition: as before, no default executable associated to .yml extension. So as before > start C:\Users\me\AppData\Roaming\lazycli\config\config.yml result in Windows to open a popup to let me select an editor.

Now get the fix and build it

> cd lazycli\
> gh pr checkout https://github.com/jesseduffield/lazycli/pull/13
> cargo install --path .
> lazycli.exe -- dir /B

It result in a first empty Error message box

The $ key produce same sort of result.

[jesseduffield]

damn. Not sure where to start to investigate this

[michelepagot]

Maybe you can allow the user to specify editor to use using environment variables.

export LAZYCLI_EDITOR=vim

or

set LAZYCLI_EDITOR=notepad.exe

run_command too is not so Windows friendly

I'm definitely not RUSTy enough to provide anything more than a pseudocode idea but maybe you can think about adding to src\os_commands.rs something like

#[cfg(target_os = "linux")]
pub fn get_executor() -> &str {
  &String::from("bash")
}

#[cfg(target_os = "macos")]
pub fn get_executor() -> &str {
  &String::from("bash")
}

#[cfg(target_os = "windows")]
pub fn get_executor() -> String {
  &String::from("cmd")
}

And then use it in

pub fn run_command(command: &str) -> Result<String, String> {
  let output = Command::new(os_commands::get_executor())
    .args(&["/c", command])
    .output()
    .expect(&format!("failed to run command {}", command));

  if !output.status.success() {
    return Err(String::from_utf8(output.stderr).unwrap());
  }

  Ok(String::from_utf8(output.stdout).unwrap())
}

Just pseudocode, it does not build. It has quite like to be extended to .args(&[ as bash need -c and cmd needs /c You can eventually also allow the user to specify his/her own executor using an environment variable