Announcement

Collapse
No announcement yet.

Using sed to strip sftp from url

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    How come you chose perl rather then bash?
    There were a few reasons, but mostly because I knew I was going to use datastructures such as arrays, and perl IMO handles them much better. I also only had a vague idea of what the script needed to do, and what it might need to do in the future...and I was less likely to hit a snag with perl.

    As for $1 and $2, could you elaborate?
    Well...in your script you use
    url=${1}
    To set up the $url variable using the first argument of your command, but if you Exec= something like:
    script mktorrent1 %U
    then the url is going to be the second argument $2
    (You can then use $1, which will be 'mktorrent1' to call the correct function in your script, for example...so you can have functions 'mktorrent1' and 'mktorrent2' and use the first argument ($1) to choose which function you want to execute...of course you don't need to do it with separate functions, you can just check the arguments and let the script behave accordingly with 'if' or 'case' statements, as in 'if the first argument $1 is this...do this' etc.)

    Leave a comment:


  • Xplorer4x4
    replied
    That's what I suspected, but I really see no point in making a deb for a shell script and service menu file unless I was distributing it.

    Leave a comment:


  • james147
    replied
    Originally posted by Xplorer4x4 View Post
    Thanks for the tips. What do you mean packaging the scripts properly?
    I mean creating a package that can be installed by dpkg (ie a .deb) but this might might more effort then it is worth.

    Leave a comment:


  • Xplorer4x4
    replied
    Originally posted by james147 View Post
    The perl syntax is different to bash, but it doesn't matter what language the files you execute are in as along as the top line points to the right executable: #!/bin/bash tells the system to use bash to execute them when they are called. However I would suggest either using /usr/local/bin or packaging up your scripts properly.

    /usr/bin generally contains binrary files that are managed by the package manager and /usr/local/bin contains custom binrary files that you have installed manually. This makes it easier to find and manage your scripts over the ones that the package manager installed.
    Thanks for the tips. What do you mean packaging the scripts properly?

    Originally posted by kubicle View Post
    I'm aware of that, I wrote the thing

    You can probably get it to work remembering that $1 would contain your subroutine and the url would be $2. I suggested separate scripts as that would be simpler, you can of course do it anyway you like.
    I didn;t feel like looking it up but thanks for writing it! Very useful! How come you chose perl rather then bash?

    As for $1 and $2, could you elaborate?

    Leave a comment:


  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    And the additionally question, actually I can confirm it is possible! I remebered that oen of the Root Actions Service Menus does it but they use perl script located in /usr/bin/.
    I'm aware of that, I wrote the thing

    You can probably get it to work remembering that $1 would contain your subroutine and the url would be $2. I suggested separate scripts as that would be simpler, you can of course do it anyway you like.

    Leave a comment:


  • james147
    replied
    The perl syntax is different to bash, but it doesn't matter what language the files you execute are in as along as the top line points to the right executable: #!/bin/bash tells the system to use bash to execute them when they are called. However I would suggest either using /usr/local/bin or packaging up your scripts properly.

    /usr/bin generally contains binrary files that are managed by the package manager and /usr/local/bin contains custom binrary files that you have installed manually. This makes it easier to find and manage your scripts over the ones that the package manager installed.

    Leave a comment:


  • Xplorer4x4
    replied
    Originally posted by kubicle View Post
    You wouldn't, unless you were testing the script in a shell instead of from dolphin...which is what I did.

    As for the additional question, it's probably doable (with modifications to the script), but for simplicity's sake it might make sense to make two scripts rather than combining the two options into one script. And use exec lines similar to:

    Exec=/path/to/mktorrent-1.sh %U
    Exec=/path/to/mktorrent-2.sh %U
    I didnt read it throughly and see you were inputting a path to a file. I thought it was just a log in.

    And the additionally question, actually I can confirm it is possible! I remebered that oen of the Root Actions Service Menus does it but they use perl script located in /usr/bin/. The actual script uses a format like:
    Code:
    sub dosomething{
    something
    to
    do
    }
    Not sure if this is simply due to the perl syntax as I have no experience with perl at all, So it may take some work like you said, and I dont mind having the bash files in the /usr/bin/ folder to keep the service menu folder more organized.

    Leave a comment:


  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    Ah I realized that the first part of that line was calling the script but the url is being passed from Dolphin so why would you call the url alongside the script? :s
    You wouldn't, unless you were testing the script in a shell instead of from dolphin...which is what I did.

    As for the additional question, it's probably doable (with modifications to the script), but for simplicity's sake it might make sense to make two scripts rather than combining the two options into one script. And use exec lines similar to:

    Exec=/path/to/mktorrent-1.sh %U
    Exec=/path/to/mktorrent-2.sh %U

    Leave a comment:


  • Xplorer4x4
    replied
    Ah I realized that the first part of that line was calling the script but the url is being passed from Dolphin so why would you call the url alongside the script? :s


    Also, I was thinking I need to duplicate this one more time. Now I could make the script call from in the service menu file but would still have to scripts in the ServiceMenu folder. So what if did:
    Code:
    #!/bin/bash
    mktorrent-1() {
    loop here
    }
    
    if [ -z "${1}" ] ; then
    echo "Not enough arguments, exiting"
        exit 1
    fi
    
    for file in ${@} ; do
    mktorrent-1 ${file}
    done
    Code:
    mktorrent-2() {
    loop here
    }
    
    if [ -z "${1}" ] ; then
    echo "Not enough arguments, exiting"
        exit 1
    fi
    
    for file in ${@} ; do
    mktorrent-2 ${file}
    done
    This is intended to be a single bash script just placed in 2 code tags for readability. Anyways would it be possible to execute the different loops from with in one service menu using 2 different exec lines like so:
    Code:
    Exec=/path/to/script.sh mktorrent-1 %U
    Exec=/path/to/script.sh mktorrent-2 %U
    This way depending on which service menu text I click, it executes either mktorrent-1 or mktorrent-2?

    Leave a comment:


  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    Sorry but I am not sure how I can clarify it any more. Did you check the output with in the quote? That's the out put exactly as it is echoed through konsole(modified path of course).
    The output you quoted looks to me very similar to my output...of course my first line is just me running the script: "./test sftp://user@hostname.domain/path/to/file" and not part of the output.

    I tested it though and it worked!
    Good to hear

    Leave a comment:


  • Xplorer4x4
    replied
    Originally posted by kubicle View Post
    I'm not sure I understand what you mean...could you elaborate?
    Sorry but I am not sure how I can clarify it any more. Did you check the output with in the quote? That's the out put exactly as it is echoed through konsole(modified path of course).

    Did you remove the "exit 0 # EXITING FOR TESTING PURPOSES ONLY" line? I just added it to exit before actually doing anything.
    Nope, sorry I saw that but didn't examine it closely and thought the whole line was commented out.

    I tested it though and it worked! Thank you so much! I been working on this off and on for a few months.

    Leave a comment:


  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    There was no "sftp://user@hostname.domain/path/to/file" like you had one line one of the first result
    I'm not sure I understand what you mean...could you elaborate?

    and I see no torrent file created.
    Did you remove the "exit 0 # EXITING FOR TESTING PURPOSES ONLY" line? I just added it to exit before actually doing anything.

    Leave a comment:


  • Xplorer4x4
    replied
    The result was a little different then the first.
    url: sftp://user@hostname.domain/path/to/file
    sftp://user@hostname.domain/path/to/file is sftp
    stripedurl: /path/to/file
    There was no "sftp://user@hostname.domain/path/to/file" like you had one line one of the first result, and I see no torrent file created.

    Leave a comment:


  • kubicle
    replied
    Originally posted by Xplorer4x4 View Post
    I tried everything here and they still echo back the entire protocol/url. I am wondering if theres an error else where.
    I think your problem might be your if statement for checking path validity...you are also missing the final backtick on your stripedurl, but I'd estimate your script might exit before that happens:

    test example:
    Code:
    #!/bin/bash
    mktorrent() {
        url=${1}
        echo "url: $url" # debug line
    
    case $url in
      "sftp://"*) echo "$url is sftp";;
      
      *) echo "not sftp, exiting"; return 1 ;;
    esac
    
    
        stripedurl=`echo "${url}" | sed "s=^sftp://[^/]*=="`
    
        echo "stripedurl: $stripedurl" # debug line
     
    exit 0 # EXITING FOR TESTING PURPOSES ONLY
        if ssh user@host "mktorrent -a 'http://site/key/announce' -p -l 21 '${stripedurl}'"; then
    kdialog --passivepopup "Completed mktorrent" 60
        else
    kdialog --passivepopup "Failed mktorrent" 60
            return 1 # Change to exit 1 to stop the script on first failure
        fi
    
    echo "Finished" # debug line
    }
    
    if [ -z "${1}" ] ; then
    echo "Not enough arguments, exiting"
        exit 1
    fi
    
    for file in ${@} ; do
    mktorrent ${file}
    done
    Results:
    ./test sftp://user@hostname.domain/path/to/file
    url: sftp://user@hostname.domain/path/to/file
    sftp://user@hostname.domain/path/to/file is sftp
    stripedurl: /path/to/file
    @jlittle: people that think outside the box are unnerving

    Leave a comment:


  • Xplorer4x4
    replied
    I tried everything here and they still echo back the entire protocol/url. I am wondering if theres an error else where. Whole script:

    Code:
    #!/bin/bash
    mktorrent() {
        url=${1}
        echo "url: $url" # debug line
    
        if echo "$url" | grep -Ev "s=^sftp://[^/]*=="; then
    echo "Not a valid remote path: $url"
            return 1
        fi # This part checks for the sftp://user@host and returns if it is not found, this should stop it from running on files not accessed via sftp
    
        stripedurl=`echo "${url}" | sed "s=^sftp://[^/]*=="
    
        echo "stripedurl: $stripedurl" # debug line
    
        if ssh user@host "mktorrent -a 'http://site/key/announce' -p -l 21 '${stripedurl}'"; then
    kdialog --passivepopup "Completed mktorrent" 60
        else
    kdialog --passivepopup "Failed mktorrent" 60
            return 1 # Change to exit 1 to stop the script on first failure
        fi
    
    echo "Finished" # debug line
    }
    
    if [ -z "${1}" ] ; then
    echo "Not enough arguments, exiting"
        exit 1
    fi
    
    for file in ${@} ; do
    mktorrent ${file}
    done

    Leave a comment:

Users Viewing This Topic

Collapse

There are 0 users viewing this topic.

Working...
X