-2

i am writing script which does git release branch merge to master then develop branch and deletes current branch and creates new branch off of develop branch. which involves 4 steps

  1. release branch to master
  2. master to develop
  3. delete current branch
  4. create new branch off of develop

how to do in shell script which displays only 4 steps and step status instead of printing whole output in console.

My desired output is

  • release branch to master Pass
  • master to develop Pass
  • delete current branch Pass
  • create new branch off of develop Pass

SUCCESS

vinod
  • 101
  • 8

1 Answers1

0

You could redirect stdout and stderr of each individual command to /dev/null or, better, to a log file, and only echo a description to your steps to the console, i.e.:

echo Deleting current branch
git branch -d fluffy 2>&1 >$LOG
if (($?==0)) then
  echo passed
else
  echo failed
fi

I personally would however do it like this:

echo Deleting current brach
git branch -d fluffy >$LOG
if (($?==0)) then
  echo passed
fi

The reason is that when a git command fails, we usually do get error information on stderr, and in this case, we want to see the error message.

Another way (which I would not recommend, but still would fit your requirement) is to redirect the output of the whole script to a log file, and print your status messages explicitly to the console:

echo Deleting current branch >/dev/tty

This means, however, that this script can only be sensibly used interactively, i.e. when you do have a console.

user1934428
  • 19,864
  • 7
  • 42
  • 87
  • The very *purpose* of the `if` statement is to run a command and check its return code. You should *very* rarely need to examine `$?` directly in a conditional. The idiomatic way to write this is simply `if git something >"$log"; then` or perhaps in this context `git something >"$log" && echo success` – tripleee Jan 10 '18 at 08:10
  • Also, tangentially, don't use uppercase for your private variables. – tripleee Jan 10 '18 at 08:13
  • You're right that in this concrete case, I should not have tested $? explicitly. I thought the logic might be easier to understand for the OP. In any case, it is a technically correct way to write it, and the whole point is not the detection of the error (which sometimes can't be done by only checking the exit code anyway), but in how to separate console output from the output of the respective commands. – user1934428 Jan 10 '18 at 08:17
  • @tripleee : I didn't make any assumption on `LOG`. I personally use upper-case for exported variables and lower-case or mixed-case for non-exported ones, and we don't know anything about this variable, so for the example anything would be fine. BTW, in my own scripts, variables denoting a preferred logfile or logdirectory often happen to be exported variables, passed through from some parent script. But of course, in this case writing `$log` is equally well. If the OP adopts my solution, he certainly knows the name of the variable which holds his log file. ;-) – user1934428 Jan 10 '18 at 08:21
  • There is a clause in POSIX which has been interpreted to mean that uppercase is reserved for "system variables", whatever that means. You see uppercase used carelessly a lot (especially the classic -- replacing `PATH` with a random variable of your own and wondering why your script says command not found) so my personal recommendation is lowercase or mixed case for everything, though I suppose the jury is still out on what exactly we mean by "system variables". – tripleee Jan 10 '18 at 08:24
  • @tripleee : I haven't heard yet this restriction about *system variables*. Do you by chance have a reference to it? I always thought (but can't give a reference), that **environment** variables (which means in shell: Exported variables) should be all-uppercase, because the system function `getenv` was originally defined to be portable only for upper case environment variables. That's why I always used upper-case for exported variables. – user1934428 Jan 10 '18 at 12:41
  • 1
    If I had an authoritative source I would make a stronger statement. But the best I can give you here and now is https://stackoverflow.com/questions/673055/correct-bash-and-shell-script-variable-capitalization where the accepted answer by lhunath makes the case that if you aren't sure, avoiding uppercase is certainly a wise decision, regardless of what exactly the applicable standards dictate. I would however argue that this should also apply to exported variables, which lhunath excludes. – tripleee Jan 10 '18 at 12:47
  • thanks @user1934428 ur explanation gave me idea on how to proceed further – vinod Jan 10 '18 at 17:29
  • @tripleee : Consider the following situation: I'm in a Cygwin shell script, setting `export foo=bar`. Now I call `cmd /c my_windows_prog.exe`. First question: Should this EXE access the variable as `getenv("foo")` or `getenv("FOO")`, given that Windows for all that I know secretly takes all environment variables upper case, even if we set them lower case? Next, my exe is invoking again a script from the Cygwin world: `system("c:\\cygwin\\bin\\zsh.exe -c my_script.sh")`, and my_script wants to read this variable. Is it still `foo`, or was it translated by cmd.ext to `FOO`? – user1934428 Jan 10 '18 at 18:25
  • I often recommend considering dropping Windows but that's probably not what you want to hear. In a discussion about POSIX behavior, pulling in compatibility with other platforms is IMHO disingenuous at best. It's a consideration, but a tangential one here. – tripleee Jan 10 '18 at 18:31
  • @tripleee : I also recommend dropping Windows, but it's usually not the programmer who decides. I don't know how it is in other countries, but on the projects I did during the last 15 years (approximately), the development platform was always a mixcture of Cygwin (scripting etc.) with native Windows applications, and there was always, no exception, the case that in the stack of child processes, Windows and Cygwin was mixed. We don't have to enjoy it, but we have to live with it. – user1934428 Jan 11 '18 at 09:40
  • @tripleee : I just found a discussion in the [Cygwin mailing list](https://cygwin.com/ml/cygwin/2004-08/msg00818.html), dealing with this issue. I also found style guides supporting your argument (all upper case reserved for system variables), and for my convention (for instance [here](https://en.wikibooks.org/wiki/Guide_to_Unix/Environment_Variables). Things get even more complicated in that it is not clear what is a "system variable". Is it one defined by the shell? In this case, many shells define lower case variables, for instance `zsh_eval_context` or `histchars`in Zsh. – user1934428 Jan 11 '18 at 09:53