You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/ShellCommandExecutor.ts
+11-2Lines changed: 11 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -152,10 +152,19 @@ export class ShellCommandExecutor {
152
152
if(awaitparsing_process.processRest()){
153
153
// Parsing the rest of the variables succeeded
154
154
// Execute the shell command.
155
+
// TODO: Create a new class ShellCommandParsingProcess (extends ParsingProcess) whose .getParsingResults() returns the shell_command_parsing_result below. I.e. extract the parsing result conversion logic to a separate class. Note that the class should only accept shell_command_parsing_map (defined in TShellCommand.ts) as it's original_contents parameter/property.
// Get a list CustomVariables that the shell command uses.
569
561
constcustom_variables=newVariableSet();
570
-
constreadVariablesFrom=this.getWrappedShellCommandContent();// FIXME: Should actually include also other stuff that uses variables when executing shell commands, e.g. output wrappers. I think the best solution would be to call TShellCommand.createParsingProcess() and then get all variables from all the parseable content. Afterwards, delete the parsing process without actually parsing it, as the result would not be needed anyway. ParsingProcess class could have a new method named .getUsedVariables() that would wrap the global getUsedVariables() function and get variables used in that particular ParsingProcess.
: this.getShellCommandContent()// Use unwrapped content.
570
+
;
571
+
// FIXME: readVariablesFrom should actually include also other stuff that uses variables when executing shell commands, e.g. output wrappers. I think the best solution would be to call TShellCommand.createParsingProcess() and then get all variables from all the parseable content. Afterwards, delete the parsing process without actually parsing it, as the result would not be needed anyway. ParsingProcess class could have a new method named .getUsedVariables() that would wrap the global getUsedVariables() function and get variables used in that particular ParsingProcess.
constaliasParsingResult: ParsingResult=parsing_results["alias"]asParsingResult;// as ParsingResult: Tells TypeScript that the object exists.
69
-
constunwrappedShellCommandParsingResult: ParsingResult=parsing_results.unwrappedShellCommandContentasParsingResult;// as ParsingResult: Tells TypeScript that the object exists.
69
+
constunwrappedShellCommandParsingResult: ParsingResult=parsing_results.shellCommandContentasParsingResult;// as ParsingResult: Tells TypeScript that the object exists.
70
70
title=aliasParsingResult.parsed_content||unwrappedShellCommandParsingResult.parsed_contentasstring;// Try to use a parsed alias, but if no alias is available, use a (short, unwrapped) parsed shell command instead. as string = parsed shell command always exist when the parsing itself has succeeded.
71
71
debugLog(debugLogBaseMessage+"Menu title parsing succeeded. Will use title: "+title);
// Try to process variables that can be processed before performing preactions.
331
331
awaitparsing_process.process();
332
332
}
333
-
if(parsing_process.getParsingResults().wrappedShellCommandContent?.succeeded){// .wrappedShellCommandContent should always be present (even if parsing did not succeed), but if it's not, show errors in the else block.
constshellCommandContentParsingSucceeded=parsingResults.shellCommandContent?.succeeded;// .shellCommandContent should always be present (even if parsing did not succeed), but if it's not, show errors in the else block.
335
+
constshellCommandWrapperParsingSucceeded=parsingResults.shellCommandWrapper ? parsingResults.shellCommandWrapper.succeeded : true;// If no wrapper is present, pass.
336
+
if(shellCommandContentParsingSucceeded&&shellCommandWrapperParsingSucceeded){// FIXME: This should not rely on just one (or two) content's parsing result, it should check all of them. Use parsing_process.getErrorMessages().length === 0 to check all parsed content.
334
337
// The command was parsed correctly.
335
338
constexecutor_instance=newShellCommandExecutor(// Named 'executor_instance' because 'executor' is another constant.
name: generateObsidianCommandName(this,t_shell_command.getUnwrappedShellCommandContent(),t_shell_command.getAlias()),// Will be overridden in command palette, but this will probably show up in hotkey settings panel - at least if command palette has not been opened yet since launching Obsidian. Also note that on some systems async variable parsing might make name generation take so long that after the name is updated in the Command object, it will not reflect in the visual menu anymore. This has happened at least on File menu on macOS, so I suspect it might concern Command palette, too. See GitHub #313 / #314 for more information. As this early name setting has been in place from the very beginning of the SC plugin, it (according to my knowledge) has protected the command palette from having similar problems that context menus have had.
354
+
name: generateObsidianCommandName(this,t_shell_command.getShellCommandContent(),t_shell_command.getAlias()),// Will be overridden in command palette, but this will probably show up in hotkey settings panel - at least if command palette has not been opened yet since launching Obsidian. Also note that on some systems async variable parsing might make name generation take so long that after the name is updated in the Command object, it will not reflect in the visual menu anymore. This has happened at least on File menu on macOS, so I suspect it might concern Command palette, too. See GitHub #313 / #314 for more information. As this early name setting has been in place from the very beginning of the SC plugin, it (according to my knowledge) has protected the command palette from having similar problems that context menus have had.
352
355
// Use 'checkCallback' instead of normal 'callback' because we also want to get called when the command palette is opened.
353
356
checkCallback: (is_opening_command_palette): boolean|void=>{// If is_opening_command_palette is true, then the return type is boolean, otherwise void.
/** Don't confuse this name with ShellCommandParsingResult interface! The properties are very different. TODO: Rename ShellCommandParsingResult to something else. */
376
-
constshellCommandParsingResult: ParsingResult=parsingResults.unwrappedShellCommandContentasParsingResult;// Use 'as' to denote that properties exist on this line and below.
379
+
constshellCommandParsingResult: ParsingResult=parsingResults.shellCommandContentasParsingResult;// Use 'as' to denote that properties exist on this line and below.
0 commit comments