AtomLinter / linter-puppet-lint

Atom linter plugin for Puppet, using puppet-lint
6 stars 3 forks source link

Error importing function definition #116

Closed rutgoff closed 7 years ago

rutgoff commented 7 years ago

linter-puppet-lint version: 0.8.1 Atom Version: 1.12.8 OS version: macOS Sierra 10.12.2

When saving any puppet file and the linter is kicked off the following error is given:

Error: sh: droprole: line 1: syntax error: unexpected end of file
sh: error importing function definition for `droprole'
sh: assumerole: line 1: syntax error: unexpected end of file
sh: error importing function definition for `assumerole'
    at ChildProcess.<anonymous> (/Users/rday/.atom/packages/linter-puppet-lint/node_modules/sb-exec/lib/index.js:56:20)
    at emitTwo (events.js:106:13)
    at ChildProcess.emit (events.js:191:7)
    at maybeClose (internal/child_process.js:877:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:226:5)

The functions referenced droprole and assumerole are custom ones from my ~/.profile. They are reproduced below and are used to change roles into other AWS accounts that I work with.

# changing AWSCLI role function
function assumerole() {
  # set $acct_id to the account number and $session_name to the user input
  acct_id=$1
  session_name="$2"

  # set the account role with the account-id and awk out the access key, secret key, and session token to an array
  #aws_creds=(`aws sts assume-role --role-arn "arn:aws:iam::$acct_id:role/etFullAccess" --role-session-name "$session_name" | grep CREDENTIALS | awk '{print $2 " "  $4 " " $(NF)}' `)
  # do the same thing but with JSON and jq
  aws_creds=(`aws --output json sts assume-role --role-arn "arn:aws:iam::$acct_id:role/etFullAccess" --role-session-name "$session_name" | jq '.Credentials.AccessKeyId,.Credentials.SecretAccessKey,.Credentials.SessionToken' --raw-output `)

  # export the array contents to the right variables
  export AWS_ACCESS_KEY_ID="${aws_creds[0]}"
  export AWS_SECRET_ACCESS_KEY="${aws_creds[1]}"
  export AWS_SESSION_TOKEN="${aws_creds[2]}"
}

export -f assumerole

# reverting AWSCLI role function
function droprole() {
  # sometimes you need to drop the session before the token times out
  unset AWS_SESSION_TOKEN AWS_SECRET_ACCESS_KEY AWS_ACCESS_KEY_ID
}

export -f droprole

They are exported and so show up in my environment, reproduced below.

10:06:47 rday@rdays-mbpro:~/Documents/RRD/ssh $ env
...
BASH_FUNC_droprole%%=() {  unset AWS_SESSION_TOKEN AWS_SECRET_ACCESS_KEY AWS_ACCESS_KEY_ID
}
BASH_FUNC_assumerole%%=() {  acct_id=$1;
 session_name="$2";
 aws_creds=(`aws --output json sts assume-role --role-arn "arn:aws:iam::$acct_id:role/etFullAccess" --role-session-name "$session_name" | jq '.Credentials.AccessKeyId,.Credentials.SecretAccessKey,.Credentials.SessionToken' --raw-output `);
 export AWS_ACCESS_KEY_ID="${aws_creds[0]}";
 export AWS_SECRET_ACCESS_KEY="${aws_creds[1]}";
 export AWS_SESSION_TOKEN="${aws_creds[2]}"
}
...
10:08:21 rday@rdays-mbpro:~/Documents/RRD/ssh $
mschuchard commented 7 years ago

This doesn't immediately look like a linter-puppet-lint issue. Would you mind cross-posting this issue at sb-exec's github project and seeing if it can be resolved from there?

rutgoff commented 7 years ago

I sure can, thanks!

Submitted as: https://github.com/steelbrain/exec/issues/72

steelbrain commented 7 years ago

@mschuchard This is neither an issue with sb-exec, nor an issue with linter-puppet-lint, this is an issue with the user configuration or the programs being executed externally. sb-exec shows up in stack because that's where the error object is constructed from stderr.

Thanks @rutgoff for opening the issue on that repo, appreciate you trying to find the root case of the bug. There's a lot of possibilities on what could be the real cause of the error, one of them is having CRLF line endings in bash files being executed. There have been similar issues for users of linter-flake8 as well as linter-puppet-lint. Perhaps their solution works for you, I wish you luck

mschuchard commented 7 years ago

Thanks @steelbrain for jumping in to help. @rutgoff If this is indeed what steelbrain is hypothesizing, then this could be the famous Fedora BASH bug that has come up three times for me already. Are you using Fedora by any chance? If so, please consult the link steelbrain provided above.

rutgoff commented 7 years ago

@mschuchard SOrry for the delay in getting back to you. No I am not using Fedora, I am using macOS

OS version: macOS Sierra 10.12.2

I have also checked my ~/.profile and there are no CRLF line endings.

steelbrain commented 7 years ago

@rutgoff I'm on macOS as well, can you please provide some repro steps? They'll help me narrow it down

rutgoff commented 7 years ago

@steelbrain I sure can.

With those functions in your ~/.profile, do:

Here's a screencast of it happening: https://youtu.be/iHadltR0ET0

steelbrain commented 7 years ago

@rutgoff I think I found the error

So there's different types of .profile files, there's the global ones that are executed regardless of the shell, then there are ones that are specific to the shell.

The cross-shell scripting language syntax of declaring a function is

function assumerole {
  echo "hi $1"
}

but the syntax you are using is

function assumerole() {
  ...
}

It's not very portable and breaks shells that don't support it (it broke my zsh), therefore the solution would be to move that specific code from ~/.profile to ~/.bash_profile or ~/.zshrc depending on you shell, let me know if it works

rutgoff commented 7 years ago

@steelbrain Will try that now

rutgoff commented 7 years ago

@steelbrain That didn't help, but not exporting them (commenting out the export lines) DID make the error go away. And to boot even with a new shell (so a new env) the functions (now in ~/.bash_profile) still work!

Something about exporting them is the root cause, but I am happy with not exporting them as they still work for my needs.

(TBH I can't remember why I exported them in the first place)