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

Allow setting the working directory for commands #941

Closed
bjorn opened this issue May 12, 2015 · 16 comments
Closed

Allow setting the working directory for commands #941

bjorn opened this issue May 12, 2015 · 16 comments
Labels
feature It's a feature, not a bug.

Comments

@bjorn
Copy link
Member

bjorn commented May 12, 2015

It would be nice if the working directory could be specified for the custom commands.

Suggested magic variables:

  • %executablePath - the path of the executable that's supposed to be run
  • %mapPath - the path of the current map file

Originally requested at issue #940.

@bjorn bjorn added the feature It's a feature, not a bug. label May 12, 2015
@IMMZ
Copy link
Contributor

IMMZ commented Jun 27, 2015

Implementation is on the way.

Questions:

  1. How to get '%executablepath%' if user only specified binary file without full path (for example, 'geany %mapfile')?
  2. Has 'xterm' some parameter to specify working dir? Can't google some...

@bjorn
Copy link
Member Author

bjorn commented Jun 27, 2015

How to get '%executablepath%' if user only specified binary file without full path (for example, 'geany %mapfile')?

One way would be to search the directories in PATH for that executable, but this is tricky and depends on the operating-system. So I'd suggest that in this case, %executablePath is simply an empty string.

Has 'xterm' some parameter to specify working dir? Can't google some...

Why would you need this? You're supposed to set the working directory using QProcess::setWorkingDirectory.

@IMMZ
Copy link
Contributor

IMMZ commented Jun 27, 2015

I thought with QProcess::setWorkingDirectory(...) xterm itself runs with working directory, not the process set by user, so it's possible it's not true and I didn't touch 'terminal running' code.

@bjorn
Copy link
Member Author

bjorn commented Jun 27, 2015

I thought with "QProcess::setWorkingDirectory(...)' xterm itself runs with working directory, not the process set by user, so it's possible it's not true and I didn't touch 'terminal running' code.

That might very well be and depends on the behavior of xterm, but it's outside the scope of Tiled to resolve such an issue.

@bjorn
Copy link
Member Author

bjorn commented Jun 27, 2015

Hmm, sorry, I just realized there is an "Execute in Terminal" option in the context menu, though it currently only shows up with Qt 4. I'll push a fix to bring it back for Qt 5.

Edit: pushed in change a9292b5

@bjorn
Copy link
Member Author

bjorn commented Jun 27, 2015

@IMMZ I quickly checked, and the working directory of the process run with xterm -e is matching with the working directory in which xterm was run. Just check for example the output in the window when doing:

cd /tmp
xterm -hold -e pwd

So at least when using xterm, there is no problem here.

@zcabjro
Copy link
Contributor

zcabjro commented Aug 31, 2016

Any reason this wouldn't work for map path? (command.cpp)

QString Command::finalCommand() const
{
    QString finalCommand = command;

    // Perform variable replacement
    if (MapDocument *mapDocument = DocumentManager::instance()->currentDocument()) {
        const QString fileName = mapDocument->fileName();

        finalCommand.replace(QLatin1String("%mapfile"),
                             QString(QLatin1String("\"%1\"")).arg(fileName));

        QFileInfo fileInfo(fileName);
        QString mapPath = fileInfo.absolutePath();
        finalCommand.replace(
            QLatin1String("%mapPath"),
            QString(QLatin1String("\"%1\"")).arg(mapPath));

        //...
    }

    return finalCommand;
}

@bjorn
Copy link
Member Author

bjorn commented Sep 2, 2016

@zcabjro That would work for simply adding a %mapPath variable, but this task isn't just about adding that variable but about being able to customize the working directory for the command. @IMMZ tried to implement this, but he eventually closed his pull request (#1004).

@zcabjro
Copy link
Contributor

zcabjro commented Sep 2, 2016

Fair enough. I'll open a pull request with this then since it would be useful for running command scripts relative to the map / without absolute paths.

@bjorn
Copy link
Member Author

bjorn commented Sep 2, 2016

@zcabjro Sure, looking forward to your pull request! Please keep in mind that the naming for variables has been all lower-case so far, contrary to the names I suggested in this issue, so you should make it %mappath.

@winniehell
Copy link

A few years passed and I'm having the same problem as in #258 again. 😄 I feel like %executablePath would be a workaround for that situation, so I would be interested in working on it.

@bjorn What is the expected behavior of %executablePath inside of Tiled? I don't feel like a path being relative to the Tiled executable is very helpful. Should it be configurable somewhere?

@ketanhwr
Copy link
Contributor

Hi @winniehell! This particular issue is under my proposal for GSoC '17, so I'll close this one within the next month. You can make any other suggestions here after going through my proposal once: Forum Link

@winniehell
Copy link

winniehell commented May 17, 2017

@ketanhwr That sounds great, thank you! 👍

@ketanhwr
Copy link
Contributor

Do you think it's a good idea to make a new column "Arguments" just like Qt Creator? This way, we can easily solve the %executablePath problem too in the working directory. Here's what I have in mind:

workingdir-1

@bjorn
Copy link
Member Author

bjorn commented May 29, 2017

@ketanhwr Yes, that's definitely useful. I think I've mentioned it before, since it also solves the problem that using the "Browse" button to choose the executable currently resets the command line arguments.

@bjorn
Copy link
Member Author

bjorn commented Jun 3, 2017

Closed by f59b10c

@bjorn bjorn closed this as completed Jun 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature It's a feature, not a bug.
Projects
None yet
Development

No branches or pull requests

5 participants