Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail From: =?UTF-8?B?T8SfdXo=?= Newsgroups: gnu.bash.bug Subject: Re: set -u not working as expected Date: Sun, 2 Aug 2020 11:01:02 +0300 Lines: 67 Approved: bug-bash@gnu.org Message-ID: References: <000301d66834$588493c0$098dbb40$@kalvr.net> <1867D8FC-85DD-4406-A239-3002913493AB@larryv.me> <61B2CB9D-3978-4872-B88A-1542CF95B5B9@larryv.me> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1596355271 12888 209.51.188.17 (2 Aug 2020 08:01:11 GMT) X-Complaints-To: action@cs.stanford.edu Cc: "bug-bash@gnu.org" , Kristof Burek To: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Envelope-to: bug-bash@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y1xTX81Hyjdi5WW2bNwazLr65JdnmsW/+YC6YIb4DYY=; b=a3FaJakNaao8Zo3ZPpR+KgwzO4FS/TINeF1QCxIG6hDiv/gQO4S3TyQ/ojku/giVRy SyZGYZgDXqWfSy3y34NmUJqVY5OcCvJ9L2ziBLQvZLsnVFLP5LKYB/gDFLivIEyM4rWM pHFxddN7wgeJ70clWv0i8GVadAiHJc+/kokk1n9qk73IF/8uRu4KGvFfxPlqlSE1unxJ otHTsanSFqehuMnnCzoA7VS+SXebCGuDVJhQYccg5olBFarqVFRbYIr9AgGWUYk5OfBj ssqtRHEU20Is5QGyR4n+nPHJbOyPwGDKswNUDdsnMW/bNbXd2wyAcJvMhClSZ6T7aSos ibaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y1xTX81Hyjdi5WW2bNwazLr65JdnmsW/+YC6YIb4DYY=; b=iQ6F9wdMv9A6QM+Ktws+8DjagcsJKreX1+K+Tts8NJE/BURV1Wpywsd/Lauim7acU4 UcKjYTicC+XsdzK0RaoC3J8b8aSJ2HBNac142E1NoGateWyq7ZswmRNCQ7iS5sBNVeOX pnU7wg+EXHOnFgmgoJuXyf4GBEtdmVCvKZRLz4MWWkEQeVq7koUy/kMHepJwf6iFwcfB 1N7a+Xga+iXs58+A0EOEEThSDW/nLVT2L8dIabYBdK6uLY5iYKEMLR/vFfsBD/VtjDK0 piINeQhxAmHJ7I6yQs/EgMB6Mc3U61fZI9GBuVhJX01nAb7yYKPYlVsv8TU2lrXf6ZOQ LxrA== X-Gm-Message-State: AOAM533YcXZoN/I9Fl5vi8ilzqrhcd1x7byJ6AxAnneOYa604g9xlvmx NHRFEaDXpxTl0FLDAIKKjbXiv/MtcotwpXB7/qE= X-Google-Smtp-Source: ABdhPJzrfB+GQQtzbxzheCfgQq+T+MpWy9XfOo2J2ALX1v8hcHuH0xVA7u8VjEPHdAdmN5P9T8fQCH0PvoDscFNtWdc= X-Received: by 2002:a37:9402:: with SMTP id w2mr19275qkd.329.1596355262909; Sun, 02 Aug 2020 01:01:02 -0700 (PDT) In-Reply-To: <61B2CB9D-3978-4872-B88A-1542CF95B5B9@larryv.me> Received-SPF: pass client-ip=2607:f8b0:4864:20::735; envelope-from=oguzismailuysal@gmail.com; helo=mail-qk1-x735.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: X-Mailman-Original-References: <000301d66834$588493c0$098dbb40$@kalvr.net> <1867D8FC-85DD-4406-A239-3002913493AB@larryv.me> <61B2CB9D-3978-4872-B88A-1542CF95B5B9@larryv.me> Xref: csiph.com gnu.bash.bug:16675 2 A=C4=9Fustos 2020 Pazar tarihinde Lawrence Vel=C3=A1zquez = yazd=C4=B1: > > On Aug 2, 2020, at 2:51 AM, O=C4=9Fuz wrote= : > > > > `u' has no members, so there's nothing to expand. If you use `${u[0]}' > for > > example, you'll see an error, I think how bash and ksh behave is > perfectly > > reasonable. > > Agreed. Their behavior logically follows from POSIX's carveout for $@. > > >> % bash -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"' > >> bash: v: unbound variable > >> % ksh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"' > >> ksh: v: parameter not set > >> % zsh -c 'set -u; typeset -i v; printf "<%s>\\n" "$v"' > >> <0> > >> > >> > > `typeset -i v' doesn't assign `v', just gives it the integer attribute. > > Again, I can't see any problem with bash and ksh here. > > Also agreed, but I was more interested in the next part... > > >> % bash -c 'set -u; typeset -i v; v+=3D1; printf "<%s>\\n" "$v"' > >> <1> > >> % ksh -c 'set -u; typeset -i v; v+=3D1; printf "<%s>\\n" "$v"' > >> <1> > >> % zsh -c 'set -u; typeset -i v; v+=3D1; printf "<%s>\\n" "$v"' > >> <1> > > ...which contrasts with the behavior of let. Someone else will have > to explain this, as I don't know what to make of it. > > Yeah, that's interesting. See this one: $ set -u $ unset foo bar $ typeset -i foo bar $ $ foo+=3Dfoo+1 $ $ foo+=3Dbar+1 bash: bar: unbound variable Only referencing `bar' triggers the _unbound variable_ error, it makes sense that the name being assigned is immune to that. Concerning `let v+=3D1', let is not a declaration utility, it's arguments a= re arithmetic expressions to be evaluated. And in arithmetic evaluation context: > Shell variables are allowed as operands; parameter expansion > is performed before the expression is evaluated. > vq --=20 O=C4=9Fuz