### Description
When an ID is defined using `!#defexps` it cannot be used in modparam
### Troubleshooting
```
#!define TEST1 "key=s:value"
## this works
modparam("pv", "varset", TEST1)
# in shell: export TEST2='key=s:value'
#!defenvs TEST2
modparam("pv", "varset", TEST2)
# this does not work
#!defexps TEST3 "key=s:value"
modparam("pv", "varset", TEST3)
0(2437437) CRITICAL: <core> [core/cfg.y:3900]: yyerror_at(): parse error in config file kamailio.cfg, line 85, column 26-32: syntax error
```
#### Reproduction
* in config file, define ID with `#!defexps` then use in `modparam()`
#### Debugging Data
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3631
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3631(a)github.com>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [x] Small bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [ ] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
kamctl now sources the kamctlrc from only one location if available in this order:
1. same folder as kamctl,
2. {intstall_prefix}/etc/kamailio/,
3. ~/.kamctlrc
4. /etc/kamailio/.
If no kamctlrc is found, it continues just like before. Should it stop?
#### Issue description
`kamctl` uses env variables from all the config files above, and retains the env value of the latest config that declares it.
Let's say we have 3 kamctlrc files right now:
```
# first config file (same folder that kamctl resides)
# {prefix_install}/sbin/kamctlrc
...
SIP_DOMAIN=kamailio.org
DBENGINE is commented
...
```
```
# second config file
# /etc/kamailio/kamctlrc
...
SIP_DOMAIN=kam02.tst.nbg.gilawa.net
DBENGINE=MYSQL
...
```
```
# third config file
# {prefix_install}/etc/kamailio/kamctlrc
...
SIP_DOMAIN is commented
DBENGINE=MYSQL
...
```
Running `{install_prefix}/sbin/kamctl` (before changes in order) it prints :
```
Loading config file /home/xenofon/kamailio-source-install/sbin/kamctlrc
Loading config file /etc/kamailio/kamctlrc
Loading config file /home/xenofon/kamailio-source-install/etc/kamailio//kamctlrc
SIP_DOMAIN env var is kam02.tst.nbg.gilawa.net
DBENGINE env var is MYSQL
```
suggesting that env variables from multiple sources are gathered and overwritten in cases.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3594
-- Commit Summary --
* kamctl: Source only one kamctlrc
-- File Changes --
M utils/kamctl/kamctl (23)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3594.patchhttps://github.com/kamailio/kamailio/pull/3594.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/3594
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/3594(a)github.com>
Hello,
during the Kamailio Developers Meeting 2023 in Dusseldorf that took
place last week, it was proposed to obsolete modules that seem to be
unmaintained and no activity about them was noticed during the past
years. It is quite some overhead in packaging them and trying to keep
them compiling when they have external dependencies, therefore such step
should spare some resources in the future.
The list (see below) was built based on the options of those present at
the meeting, now we want to discuss it on the larger communities of
developers and users. If you are using any of these modules or you think
any of them worth keeping, reply with the names of the modules that you
want to be kept.
The proposed action is to relocate the obsoleted modules to a new git
repository "kamailio-obsolete" to still keep some visibility to them and
in the eventually of future interest on any of them, it can be
reintroduced in the main repository.
Next is the initial list of modules proposed to be considered obsolete:
- app_java
- app_lua_sr
- app_mono
- app_python
- app_sqlang
- auth_identity
- call_control
- db2_ldap
- db2_ops
- db_cassandra
- db_perldvdb
- dnssec
- domainpolicy
- h350
- mediaproxy
- osp
- peering
- print
- print_lib
- pua_xmpp
- ratelimit
- uid_auth_db
- uid_avp_db
- uid_domain
- uid_gflags
- uid_uri_db
- uri_db
- xmpp
- xprint
Cheers,
Daniel
--
Daniel-Constantin Mierla (@ asipto.com)
twitter.com/miconda -- linkedin.com/in/miconda
Kamailio Consultancy and Development Services
Kamailio Advanced Training -- asipto.com